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I. IHTBO DDCTI OH 

Databases are essential to an organization’s information 
system. The information system supports the organization’s 
functions, maintaining the data for these functions and 
assisting users to interpret the data for decision making. 
The dataiase has a central role in this process. Database 
structures must be flexible to meet changing organizational 
needs. As new functions arise in an organization, new 
decisions follow in their wake. It should include facilities 
to allow the changes to be easily made. Characteristics of 
the database system will be discussed in the Chapter 2. 

Meanwhile, it is not easy to develop database systems 
which perform in an optimal fashion. Different users will 
have different request about structuring data in the 
database. It is hard to satisfy all of the users with one 
type of structuring. There are different ways in which data 
can be structured. For that reason, in the database 
development phase all requests which come from 
users/organizations should be evaluated carefully by the 
designer (s) . 

Fcr logical design of the inventory database the 
Semantic Data Model will be used. After that, the normal 
form concept of the Relational Database will be used to. 
develop an inventory database. 

Chapter 3 describes the basic concepts of database 
design which includes the logical and physical database 
design, and database models. Chapter 4 addresses the design 
of SDH and specifications of SDM. Chapter 5 describes how 
the inventory database is design by using the SDM. Chapter 
6 addresses the basis structure of the relational model 
which includes functional dependency and normal form 



concepts of the relational model. Chapter 7 describes the 
relational design criteria and relational design procedure. 
Also, in this chapter SDM for the inventory database will be 
transformed into a relational model. In Chapter 8, as a 
relational approach to database system. System R is 
described which contains architecture and system structure, 
the relational data system, and the relational storage 
system of System E. Chapter 9 describes the implementation 
of the inventory database by using ORACLE. Finally, Chapter 
10 addresses the ccnclusions and recommendations of this 
thesis. 



II. BASI C CON CEPT OP DATABASE 
A. BEAT IS A DATABASE? 

Database technology has been described as "one cf the 
most rapidly growing areas of computer and information 
science." As a field, it is still comparatively young. 
Despite its youth, however, the field has guicXly become one 
of considerable importance, both practical and theoretical. 
Today, many organizations have become critically dependent 
on the continued and successful operation of a database 
system. 

Basically, a database is nothing more than a 
computer-based record keeping system: that is, a system 

whose overall purpose is to record and maintain information 
that may be necessary to the decision-making processes 
involved in management of that organization. In a database 
the data definitions and the relations between the data are 
separated from the procedural statements of a program. The 
guesticn to be asked here is,"Bhat is the major distinction 
between a database and a data file?" A database may have 
more than one use, and the multiple uses may satisfy 
multiple "views" of the data stored. A data file may have 
more than one use, but only one "view" of the stored data 
can be satisfied. Multiple views of a data file can be 
satisfied only after the data have been sorted. In a 
database environment, multiple uses may be the result of 
multiple users; for example, in a banking environment the 
information about customers may have several users, such as 
checking, savings, and installment loan. Thus data sharing 
is a major objective of an enterprise database system. A 
database system involves four major components: 
data, hardware, software, and users. 
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1 . Dat a 

A database is a repository for shared data. In 
general, it is both integrated and shared. ” Integrated ” 
means that the database may be thought of as a unification 
of several otherwise distinct data files, with any 
redundancy among those files partially or wholly eliminated. 
"Shared " means that individual pieces of data in the 
database may be shared among several users, in the sense 
that each ox those users may have access to the same piece 
of data. Such sharing is really a consequence of the fact 
that the database is integrated. The term "shared" is 
frequently extended tc cover not only sharing as described 
above, but also concurrent sharing: that is, the ability of 

several different users to be actually accessing the 
database at the same time. 

2 . Har dware 

The hardware consists of the secondary storage 
volumes - disks , drums, etc -on which the database resides, 
together with the associated devices, control units, 
channels, and so forth. 

3 - Softwa re 

Between the physical database itself (i.e, the data 
as actually stored) and the users of the system is a layer 
of software, usually called the database management system or 
DBMS. A database management system makes it possible to 
access integrated data that crosses operational, functional, 
or organizational boundaries within an enterprise. As an 
example of a Eelaticnal DBHS System R will be evaluated in 
Chapter 8. 
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4 . 



Users 



Three classes of users can be considered. First/ - 
there is the application programmer, responsible for writing 
application programs that use the database, typically in a 
language such as COBCI or PL/I. The second class of user is 
the end-user, accessing the database from a terminal. An 
end-user can use a guery language which as an integral part 
of the system. The third class of user is the database 
administrator, or EEA who is the person { or a group of 
persons ) responsible for overall control of the database 
syst em. 

B. OPEBATIONAL DATA 

Any enterprise such as a bank, hospital, university, or 
company must necessarily maintain large amounts of data 
about its operation, termed ’’operational data”. The 
operational data for the enterprises would probably include 
account data, patient data, student data, product data, and 
planning data. Operational data does not include input or 
output data, work gueues, or indeed any purely transient 
information. Input data refers to the information entering 
the system from the outside world; such information may 
cause a change to be made to the operational data but is not 
itself part of the database. Output data refers to messages 
and reports emanating from the system; such a report 
contains information derived from the operational data, but 
is not itself part of the database. 

C. BBT EATABASE ? 

The broad answer to this question is that a database 
system provides the enterprise with centralized control of 
its operational data. This is in sharp contrast to the 
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situation that prevails in many enterprises today where 
typically each application has its own files so that the 
operational data is widely dispersed, and therefore prohably 
difficult to control. In the database system, the DBA has 
this central responsibility for the operational data. Some 
of the advantages that accrue from having centralized 
control of the data are described below. 

1 . Advantages of Datab a se Systems 

An important advantage of database processing is the 
elimination or reduction of data duplication. In nondatabase 
system each application has its own private files. This can 
often lead to considerable redundancy in stored data, with 
resultant waste in storage space. In the database, it need 
only be recorded once. Elimination of duplication saves file 
space and to some extent can reduce processing requirements. 
In some cases there may be some business reasons for 
maintaining multiple copies of the same data. In the 
database, however, redundancy should be controlled. The most 
serious problem of data duplication is that it can lead to a 
lack of data integrity. A common result of a lack of 
integrity is conflicting reports. 

Data integration offers several important 
advantages. First and foremost, database processing enables 
more information to be produced from a given amount of data. 
Data are recorded facts or figures; information is knowledge 
gained by processing data. 

Creation of program/data independence is another 
advantage of a database system. For the database 
application, application programs will obtain data from an 
intermediary, the DBKS. The application programs need not 
contain data structure, only the DBMS will need this 
structure. Another advantage of database processing is 
better data management. When data is centralized in a 
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datatase, one departient can specialize in the maintenance 
of the data. That department can specify data standards and 
ensure that all data adhere to the standards. 

Database processing creates another type of economy 
of scale. Since there is only one DBMS processing a shared 
database, improvements made to the database or to the DBH3 
will tenefit many users. 

2- D isadvantage s of Database System s 

A major disadvantage of database processing is that 
it can be expensive. The DBMS may cost as much as 3100,000 
to buy. The database management system may occupy so much 
main memory that additional memory must be purchased. Even 
with more memory, it may monopolize the CPU, thus forcing 
the user to upgrade to a more powerful computer. Conversion 
from existing systems can be costly, especially if new data 
must te acquired. 

Another major disadvantage is that the database 
processing tends to be complex. Large amounts of data in 
many different formats can be interrelated in the database. 
Both the database system and application programs must be 
able to process these structures, requiring more 
sophisticated programming. Backup and recovery are difficult 
in the database environment because of increased complexity 
and because databases are often processed by several users 
concurrently. Determining the exact state of the database 
at the time of the failure may be a problem. A final 
disadvantage is that integration, and hence centralization, 
increases vulnerability. A failure in one component cf an 
integrated system can affect the entire system. 
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D. DATA IHDEPENDENCE 



In the conventional data set environment, the 
application programmer has to know answers to the following 
guestions before manipulating the data : 

1. What is its fcrmat? 

2. Where is it located? 

3. How is it accessed? 

Changes in any of these three items may affect the 
application program and result in other changes, since the 
details of these three points may reside in the application 
code. The users of the database system should be oriented 
toward the information content of the data and should net be 
concerned with details of the representation and location. 
The ability to use the database without knowing the 
representation details is called DATA INDEPENDENCE. Data 
independence provides that the individual application 
programmer no longer must change the application programs to 
accommodate changes in access method or location or fcrmat 
of the data. The reasons for data independence are as 
follows; 

1. To allow the DBA to make changes in the content, 
location, representation and organization of a 
database without causing reprogramming of application 
programs which use the database. 

2. To allow the supplier of data processing eguipment 
and software to introduce new technologies witnout 
causing reprogramming of the customer’s application. 

3. To facilitate data sharing by allowing the same data 
to appear to be organized differently for different 
application pregrams. 

4. To simplify application program development and, in 
particular, to facilitate the development of programs 
for interactive database processing. 
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5. To provide the centralization of control needed by 
the DBA to insure the security and integrity of the 
database. 

E. DATA EICTIOIAEY 

A data dictionary is a central repository of information 
about the entities, the data elements representing the 
entities, the relationships between the entities, their 
origins, meanings, uses, and representation formats. A 
facility that provides uniform and central information about 
all the data resources is called a DATA DICTIONARY (DD) . The 
benefits of using a data dictionary are related tc the 
effective collection, specification, and management of the 
total data resources of an enterprise. A data dictionary 
should help a database user in: 

1 . Communicating with other users. 

2. Controlling the data elements in a simple and 
effective manner; that is, introducing new elements 
into the system, or changing the descriptions of the 
element s. 

3. Reducing the data redundancy and inconsistency. 

4. Determining the impact of the changes to the data 
elements on the total database. 

5. Centralizing the control of the data elements as an 
aid in database design and in expanding the design. 
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III. DATABASE DE SIGH 



A database is the interface between people and machines. 
The nature of these components is very different. The 
difficulty is to develop a database design which meets the 
needs of the people who will use it aind which is practical 
in term of technology and hardware. Since the database is 
the bridge between humans on one side and hardware on the 
other, it must match the characteristics of each. 

There is no algorithm for database design. Database 
design is both art and science. Dealing with people, 
understanding what they want today, predicting what they 
will want tomorrow, differentiating between individual needs 
and community needs, and making appropriate design tradeoffs 
are artistic tasks. There are principles and tools, but 
these must be used in conjunction with intuition and guided 
by experience. 

Database design is a two-phased process. The first phase 
of the database design is usually called the Logical 
Database Phase in which the designer examines the users’ 
reguirements and builds a conceptual database structure that 
is a model of the organization. Once the logical design of 
the database is completed, this design is formulated in 
terms of a particular DBMS. Osually compromises must be 
made. The process of formulating the logical design in terms 
of a DBMS facility is called Physical Database Design. This 
chapter considers both phases of the database design. 

A. LOGICAL DATABASE lESIGH 

Typically, database design is an iterative process; 
during each iteration, the goal is to get closer to an 
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acceptable design. Ihus a design will be developed and then 
reviewed. Defects in the design will be identified, and the 
design will be revised. This process is repeated until the 
development team and users can find no major defects. This 
does not mean the design will work; it simply means no one 
can think of any reason why it will not work. Figure 3. 1 
illustrates the steps in a typical database design 
pro ject[ Eef . 4 ]. 
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Figure 3. 1 Database and Program Design Flow. 



Dser rsguirement s are studied and a logical database design 
is developed. Concurrently, the preliminary design of the 
database processing programs is produced. Next, the logical 
database and the preliminary program designs are used to 
develop the physical database design and the detail program 
design specifica tions. Finally, both of these are input to 
the iaplementation phase of the project. 
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1 . Inp uts to Logical Database D esig n 



Ihe inputs tc the logical database design ar€ the 
system requirements and the project plan. Requirements are 
determined by interviews with users, and then they are 
approved by both users and management. The project plan 
describes the system environment, the development plan, and 
constraints and limitations on the system design. Policy 
statements can be used to develop the descriptions of the 
logical database design. 

2 - Outputs of the Logic^ Database Design 

A logical database design specifies the logical 
format of the database. The records to be maintained, their 
contents, and relationships among these records are 
specified. 

To specify logical records, the designer must 
specify the levels of the detail of the database model. If 
the model is highly aggregated and generalized, there will 
be few records. If the model is detailed, there will be many 
records. The designer must examine the requirements to 
determine how coarse or how fine the database model should 
be. The contents of these are specified during logical 
design. Names of fields and their formats must be 
determined. As the requirements are evaluated and the design 
progresses, constraints on data items will be identified. 
These are limitations on the values that data can have. 
These types of constraints are common. Field constraints 
limit the values that a given data item can have. 
Intrarecord constraints limit values between fields within a 
given record. Also, record rela tionships are specified 

during logical design. The designer studies the application 
environment, examines the requirements, and identifies 
necessary relationships. Finally, output of the logical 
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database design is the specification of the database 
records, their contents, constraints, and relationships. 

3. Stages of Logic al D atab ase Desig n 

Many techniques have been developed for logical 
database design. Seme techniques are completely intuitive 
and others involve specific procedures for processing a data 
dictionary. Others are between these extremes. The major 
steps in the logical database design are as follows. 

a. Identify Eata to be Stored 

First, the data dictionary is processed and data 
that is to be stored is identified and segregated. This step 
is necessary because the data dictionary will contain the 
description of the reports, screens, and input documents 
that will not be part of the database. 

b. Consolidate and Clarify Data Names 

The next step is to clarify the terms used for 
the data. One task is to identify synonyms, to decide on 
standard names for synonyms, and the record aliases. 
Synonyms are two or mere names for the same data item. They 
arise because of the terminology differences within the 
organization. In this case the designer will need to select 
a single , standard name for the data item in the logical 
schema of the database. In some cases synonyms can not be 
eliminated because the users want to maintain their own 
terminology. 

Another task related to terminology is to ensure 
that data items having the same name are truly the same. If 
not, unique data item names must be developed. Consider the 
data item DATE. This can be the date of shipment, the date 
of employee termination, or the date of order. The designer 
must determine if all of the uses of the DATE item are the 
same. If not, new and unique names must be determined. 
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c. Develop the Logical Schema 



The third step in the design process is to 
develcp the logical schema by defining records and 
relationships. Records are defined by determining the data 
items they will contain. The designers examine the data flow 
diagrams and data dictionary, apply intuition to the 
business setting of the new system, and determine that 
certain records will need to exist. After this 

determination, some of the files may need to be combined and 
some of them may not. 

The second step in developing the logical schema 
is to determine the relationships among database records. At 
that point, representation of the relationships by the 
database system is net important. Instead, the design team 
wants to model how the users see the relationships. We do 
not need to consider physical limitations at this point. 
Doing so makes the logical schema too complex and may 
constrain our thinking so that we miss good design 

alternatives. At that point, the design team must 
discriminate between theoretical and useful relationships. A 
theoretical relationship can exist logically, but never be 
needed in practice. In general, if there is any question 
regarding whether a relationship is useful or not, then the 
relationship should be included in the logical schema. The 
relationship always can be omitted later in the physical 
design, whereas if the relationship were omitted during 
logical design, it would be difficult to add later. 

d. Define Processing 

The next step is to define the processing of the 
database. The requirements are examined to determine hew the 
database should be manipulated to produce required results. 
The processing definitions can be developed in several ways. 
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One method is to describe transactions and data to be 
modified. Another method is to develop structure charts of 
the programs that will access the database. This process is 
important because concurrent design of the programs and 
database will improve the database design. It is also clear 
that concurrent design improves the quality of programs. 

e. Design Review 

The final stage of the logical database design 
is a review. The logical schema and users' views are 
examined in the light of the requirements and program 
descriptions. Every attempt is made to identify omissions 
and unworkable aspects of the design. Typically, a panel of 
independent data processing people is convened for this 
review. Documentation of the logical schema, users' views, 
and program descriptions are examined by the panel, and oral 
presentations are evaluated. 

At the conclusion of the design review, the 
panel produces a list of problems discovered and a 
recommendation regarding the next step to be taken. 

B. PHYSICAL DATABASE DESIGN 

The second stage of the database design is physical 
design which is a stage of the transformation. The logical 
schema is transformed into the particular data constructs 
that are available with the DBMS to be used. As mentioned 
before, the inputs tc the physical database design are the 
outputs of the logical database design, the system 
requirements, and the preliminary design of programs. 
Whereas the logical design is DBMS independent, the physical 
design is very much lEMS dependent. Detail specification of 
the database structure is produced. These specif icaticns 
will be used during database implementation to write source 



statements that define the database structure to the DBMS. 
These statements will be compiled by the DBMS and the object 
form cf the database structure will be stored within the 
database as shown in Figure 3.2 [Ref. 4]. 




Figure 3.2 Physical Design Process. 



1 . Ph y sical D esign Steps 

Practical experience has shown that neither the 
starting point nor the order of steps can be definitely 
stated for a given design problem. On the other hand, the 
physical design phase can be regarded as an iterative 
process cf initial design and requirement. Each step needs 
to he performed several times, but succeeding analysis 
should be done more quickly because the procedure is known 
and the number of unchanging performance variables should 
increase between iterations. Steps of physical design are as 
follows. 
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a. Stored Record Format Design 

Assuming that the logical record structure- has - 
been defined, this process addresses the problem of 
formatting stored data by analysis of the characteristics of 
data item types, distribution of their values, and their 
usage by various applications. Certain data items are often 
accessed more frequently than others, but each time a 
particular piece of data is needed, the entire stored 
record, and all stored records in a physical block as well, 
must be accessed. Record partitioning defines an allocation 
of individual data items to separate physical devices of the 
same or different types, or separate extents on the same 
device, so that the total cost of accessing data for a given 
set of user applications is minimized. Logically, data items 
related to a single entity are still considered to be 
connected, and physically they can still be retrieved 
together when necessary. 

2 . Stored Record Clustering 

Record clustering refers to the allocation of the 
records of different types into physical clusters to take 
advantage of physical sequentiality whenever possible. 
Associated with both record clustering and record 
partitioning is the selection of physical block size. Blocks 
in a given clustered extent are influenced somewhat by 
stored record size, but also by storage characteristics of 
physical devices. Choice of block size may be subject to 
considerable revision during an iterative design process. 

3. Ac cess Met hod Design 

An access method provides storage and retrieval 
capabilities for data stored on physical devices, usually 
secondary storage. The two critical components of an access 
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method are storage structure and search mechanism. Storage 
structure defines the limits of possible access paths 
through indexes and stored records, and search mechanisms 
define which paths are to be taken for given applications. 
Access method design is often defined in terms of primary 
and secondary access path structure. The primary access 
paths are associated with initial record loading, or 
placement, and usually involve retrieval via the primary 
key. Secondary access paths include interfile linkages and 
alternate entry-point access to stored records via indexes 
and secondary keys. The trade-off is that access time can be 
greatly reduced through secondary indexes, but at the 
expense of increased storage space overhead and index 
maintenance. 

A fourth step of physical design trade-offs among 
integrity, security, and efficiency requirements also should 
be considered. 

a. Program Design 

The goal cf the physical data independence, if 
met, produces application program modification due to 
physical structure design decisions. Standard DBMS routines 
should be used for all accessing, and query or update 
transaction optimization should be performed at the system 
software level. Then, application program design should be 
completed when the logical database structure is known. When 
physical data independence is not guaranteed, program 

modification is likely. 

Ph y sical Des ign Env iron ment 

The design environment is basically the same for 
both file design and physical database design. Major 
categories of inputs and outputs for the physical design 
phase are illustrated in Figure 3.3. The logical database 
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structure resulting from the implementation design phase 
defines the framework from which the physical designer 
works. If no catastrophic inefficiency is detected, it will 
remain unchanged during physical design. In general, new 
parameters will be considered, but previous tentative 
decisions on access paths and record allocation are 

finalized in this phase. New parameters are those specific 
to DBMS and operating system access methods, those specific 
to describe physical device capacity limitations and timing 
characteristics, and all operational requirements which are 
constraints imposed cn integrity, security, and response 
time under static conditions and for dynamic growth 

projections. During the design process, consideration of 
efficiency issues can take place only the after various 
constraints are satisfied and a feasible solution has been 
obtained. 



5 • Performanc e Me asures 

Ihe determination of performance measures for 
physical design is most critical to the design process. They 
affect not only the design choices, but also the techniques 
employed to determine those choices. 

Multiple performance measures provide the designer 
with flexibility for decision making for both the initial 
design procedure and for future modifications. If we 
describe the database system performance in terms of cost we 
should consider life cycle cost in terms of following items: 

1. Planning cost 

2. Design cost; programs, databases 

3. Iicplementation and testing c ost; programs, databases 

4. Operational cost: users, computer resources 

5. Maintenance ccst:program errors, data integrity loss. 

The major problem that the physical database 
designer must address is how to minimize present and future 
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Figure 3.3 Physical Design Environment. 



operational costs in terms of user needs and computer 
resources. The remainder of the life cycle phases' costs are 
well defined for general software systems. Operational costs 
are unique to physical design and can be categorized as 
follows: 

1. Query response time 

2. Update transaction cost 

3. Report generation cost 

4. Reorganization frequency and cost 

5. Main storage cost 

6. Secondary storage cost 
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Each of these components is important to the 
designer; typical considerations are shown in Figure 3.4. 
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Figure 3-4 Qaery Response Time Components. 



C. EiTAFASE HODELS 

A database model is vocabulary for describing the 
structure and processing of the database. There are two 

reasons for studying database models. First, they are 

important database design tools. Database models can be used 

for toth logical and physical database design - much as 

flowcharts or pseudocode are used for programs design. 
Second, database mcdels are used to categorize DEHS 
products. Database models have two major components. First, 
the data definition language (DDL) is a vocabulary for 
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defining the structure of a database. The DDL must include 
terms for defining records, fields, keys, and relationships. 
Also it should provide a facility for expressing a variety 
of user views. As a second component, data manipulation 
language (DML) is a vocabulary for describing the processing 
of the database. Two types of DML exist: procedural and 

nonprocedural DHL. Tacilities are needed to retrieve and 
change data for both- Procedural DHL is language for 
describing actions to be performed on the database. It 

obtains a desired result by specifying the operations to be 
performed. Nonprocedural DML is language for describing the 
data that is wanted without describing how to obtain it. 

Figure 3.5 illustrates six common and useful database 
models. The models are arranged on a continuum. Models on 
the left-hand side of this figure tend to be oriented to 
humans and human meaning, whereas those on the right-hand 
side are more oriented toward machines and machine 

specif ications[ Eef. 4: p. 215], 

The primary purpose of this thesis is to design and 
implement an inventory database. For the logical design of 
this database, the Semantic Data Model (SDM) will be used 
and for physical design a Relational Model will be employed. 
For this reason, SEM and the Relational model will be 
discussed in detail in the following chapters. 
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IV. SE MANTI C DATA M ODEL ( SDM ) 



A. INTEODDCTIOB 

The Semantic Data Model was developed by M, HAMMEB and 
D. MclOED in 1981|;fief. 13 ]. SDM is a high-level 
semantics-based database description and structuring 
formalism for databases. This database model is designed to 
capture more of the meaning of an application environment 
than is possible with contemporary database models. An SDM 
specification describes a database in terms of the kinds of 
entities that exist in the application environment, the 
classifications and groupings of those entities, and the 
structural interconnections among them. SDM provides a 
collection of high-level modeling primitives to capture the 
semantics of an application environment. SDM is designed to 
enhance the ef f ectiveress and usability of database systems. 
An SDM database description can serve as a formal 
specification and documentation tool for a database. 

Every database is a model of some real world system. The 
contents of a database are intended to represent a snapshot 
of the state of an application environment and each change 
to the database should reflect an event occuring in that 
environment. It is appropriate that the structure of the 
database mirror the structure of the system that is being 
modelled [Ref . 1 3] . A database whose organization is based on 
naturally occuring structures will be easier for a database 
designer to construct and modify than one that forces him to 
translate the primitives of his problem domain into an 
artificial specification construct. Similarly, a database 
user should find it easier to understand and employ a 
database if it can be described to him using concepts with 
which he is already familiar. 
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Ccntemporary database models provide the data structures 
which do not adequately support the design, evolution, and 
use of complex databases. These models have significantly 
limited capabilities for expressing the meaning of a 
database. The semantics of a database defined ir terms of 
these mechanisms are not readily apparent from the schema 
which is the global cser view of a database; instead, the 
semantics must be separately specified by the database 
designer and consciously applied by the user. 

B. THE EESIGH OF SDH 

SDM has been defined with a number of specific kinds of 
uses in mind. First, SDM is meant to serve as a formal 
specification mechanism for describing the meaning of a 
database; an SDM schema provides a precise documentation and 
communication medium for database users. For a new user of a 
complex database, it is easy to find out what information is 
contained in the database. Second, SDM provides the basis 
for a variety of high-level semantics-based user interfaces 
to a database; these information facilities can be 
constructed as front-ends to existing database management 
systems, or as the query language of a new DBMS. Such 
interfaces improve the process of identifying and retrieving 
relevant information from the database. Finally, SDM 
provides a foundation for supporting the effective and 
structured design of databases and database intensive 
application systems. 

SDH has been designed to satisfy a number of criteria 
that are not met by contemporary database models, but are 
essential in an effective database description and 
structuring formalism. They are as f ollows[ Ref . 1 3 ] : 

**The constructs of database model should provide for the 
explicit specification of a large portion of the meaning 
of a database. Many contemporary database models (such 
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as the CODASYL DBIG network model and the hierarchical 
model) exhibit compromises between the desire to provide 
a user-oriented database organization and the need to 
support efficient database storage and manipulation 
facilities. By contrast, the relational database model 
stresses the separation • of user-level database 
specifications and underlying implementation detail (data 
independence). However, the semantic expressiveness of 
the hierarchical mcdel, network and relational models 
are limited: they do not provide sufficient mechanisms, 
to allow a database schema tc describe the meaning of a 
database. They employ overly simple data structures to 
model an application environment. In so doing, they 
inevitably lose information about the database. This is 
a conseguence of the fact that their structures are 
essentially all record-oriented constructs; the 
appropriateness and adequacy of the record construct for 
expressing database semantics is highly limited. It is 
essential that the database model provide a rich set of 
features to allow the direct modeling of application 
environment semantics. A database model must support a 
relativest view of the meaning of a database , and allow 
the structure of a database to support alternative ways 
of locking at the same information. Flexibility is 
essential in order to allow for multiple and coequal 
views of the data. In a logically redundant database 
schema, the values of some database components can be 
algorithmically derived from others. Incorporating such 
derived informa tier into a schema can simplify the 
user’s manipulation of a database by statically 
embedding in the schema data values that would otherwise 
have to be dynamically and repeatedly computed. Finally, 
an integrated schema explicitly describes the 
relationships and similarities between multiple ways of 
viewing the same information. Contemporary database 
models do not adequately support relativism. In these 
models, it is generally necessary to impose a single 
structural organization of the data, one which 
inevitably carries along with it a particular 
interpretation of the data’s meaning.” 



A database model must support the definition of schemata 
that are based on abstract entities. Specif ically, this 

means that a database model must facilitate the description 
of relevant entities in the application environment, 
collections of such entities, relationships among entities, 
and structural interconnectiens among the collections. 
Moreover, the entities themselves must be distinguished from 
their syntactic identifiers; the user-level view of database 
should be based on actual entities rather than on artificial 
entity names. Allowing entities to represent themselves 
makes it possible to directly reference an entity from a 
related one. In record-oriented database models, it is 
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necessary to cross reference between related entities by 
means of their identifiers[ Eef . 1 1 ]. 

C. A SPECIFICATIOH OF SDH 

The following general principles are specified by HcLoed 
and Hammer in 1981: 

1. A database is to be viewed as collections of entities 
that correspond to the actual objects in the 
application environment. 

2. The entities in a database are organized into classes 
that are meaningful collections of entities. 

3. The classes of a database are not generally 
independent, but rather are logically related by 
means of interclass connections. 

4. Database entities and classes have attributes that 
describe their characteristics and relate them to 
other database entities. An attribute value may be 
derived from ether values in the database. 

5. There are several primitives for defining interclass 
connections and derived attributes, corresponding to 
the most common types of information redundancy 
appearing in database applications. These facilities 
integrate multiple ways of viewing the same basic 
information, and provide building blocks for 
describing complex attributes and interclass 
relationships . 

1 . Classe s 

As mentioned above, an SDH database is a collection 
of entities that are organized into classes. Figure 4.1 
shows a basic format cf an SDH entity class description. The 
structure and organization of an SDH database is specified 
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which identifies the classes in the 



by an SDM schema, 
database. Each class in an SDM schema has the following 
features. 

1. A class name identifies the class. Multiple 
synonymous names are also permitted. Each class name 
must be unique with respect to all class names used 
in the schema. 

2. The class has a collection of members: the entities 

that constitute it. Each class in an SDM schema is a 
homogeneous collection of one type of entity at an 
appropriate level of abstraction. The entities in a 
class may correspond to various kinds of objects in 
the application environment. 

3. An optional textual class description describes the 
meaning and content of the class. A class description 
should be used to describe the specific nature of 
entities that constitute a class and to indicate 
their significance and role in the application 
environment. 

4. The class has a collection of attributes that 
describes the members of that class or the class as a 
whole. There are two types of attributes, classified 
according to applicability. 

5. A member attribute describes an aspect of each member 
of a class by logically connecting the member to one 
or more related entities in the same or other 
classes. A class attribute describes a property of a 
class taken as whole. 

6. The class is either a base class or a nonbase class. 
A base class is one that is defined independently of 
all other classes in the database; it can be thought 
of as modeling a primitive entity in the application 
environment. Ease classes are mutually disjoint in 
that every entity is a member of exactly one base 
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class. A nontase class is one that does not have 
independent existence; rather, it is defined in terms 
of one or more other classes. In SDM, classes are 
structurally related by means of interclass 
connections. Each nonbase class has associated with 
it an interclass connection. If class is base class, 
it has an associated list of groups of member 
attributes; each of these groups serves as a logical 
key to uniquely identify the members of a class. If 
the class is base class, it is specified as either 
containing duplicates or not containing duplicates. 

a. Interclass Connections 

There are two main types of interclass 
connections in SDM: the first allows subclasses to be 
defined and the second supports grouping classes. The 
subclass connection specifies that the members of nonbase 
class (S) are of the same basic entity type as those in the 
class to which it is related via interclass connection. This 
type of interclass connection is used to define a subclass 
of a given class. A subclass S of class C is a class that 
contains some, but not necessarily all, of the members of C. 
In SDH, a subclass S is defined by specifying a class C and 
a predicate P on the member of C; S consists of just those 
members of C that satisfy P. Several types of predicates are 
permissible. A predicate on the member attributes of C can 
be used to indicate which members of C are also members of 
S. The predicate "where specified" can be used to define S. 
This means that S contains at all times only entities that 
are members of C. It is also possible to define subclass S 
as an intersection of database classes ( C1,C2 ) . 

The other type of interclass connection allows 
for the definition of nonbase class, called a grouping class 
(G) , whose members are of a higher-order entity type than 
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A ttribute_name 
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Attribute_name1 +[ A ttribute_name2+[ . . ] ] ] 



Figure h. 1 Format of SDH Entity Class Description. 

those in the underlying class (0) . A grouping class is 
second order, in the the sense that its members can 
themselves be viewed as classes; in particular, they are 
classes whose members are taken from 0. 
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2 . At tributes 



Each class has aa associated collection of ■ 

attributes. Each attribute has the following features. 

1. An attribute name identifies the attribute. An 

attribute name must be unique with respect to the set 
of all attribute names used in class, the class’s 
underlying base class, and all eventual subclasses of 
that base class. 

2. The attribute has a value which is either an entity 
in the database or a collection of such entities. The 
value of an attribute is selected from its underlying 
value class, which contains the permissible values of 
the attribute. 

3. The attribute is either a member attribute which 
applies to each member of the class, and so has a 
value for each member, or a class attribute which 
applies to a classes a whole, and has only one value 
for the class. 

4. The attribute is specified as either single valued or 
multivalued. The value of a single-valued attribute 
is a member of the value class of the attribute. The 
value of a multivalued attribute is a subclass of the 
value class. Thus, a multivalued attribute itself 
defines a class, that is, a collection of entities. A 
multivalued member attribute can be specified as 
nonoverlaping which means that the values of the 
attribute for two different entities have no entities 
in common; that is, each member of the value class of 
the attribute is used at most once. 

5. An attribute can be specified as mandatory, which 
means that a null value is not allowed for it. 

6. An attribute can be specified as not changeable which 
means that once set to a nonnull value, this value 
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cannot be altered except to correct an error, 
pcintend 

a. Member Attribute Interrelationships 

(1) I nverse . The first way in which a pair 

of member attributes can be related is by means of 

inversion. Member attribute XI of class Y1 can be 
specified as the inverse of member X2 of Y2 which means 
that the value of XI for a member Ml of Y1 consists of 
those members of Y2 whose value of X2 is HI. The 

inversion interattribute relationship is specified 
symmetrically in that both an attribute and its inverse 
contain a description of the inversion relationship. A 
pair of inverse attributes establish a binary association 
between the members of the classes that the attributes 
modify. 

(2) Matchin g. The second way in which a 

member attribute can be related to other informaticn in 
the database is by matching the value of the attribute 
with some member (s) of a specified class. The value of 

match attribute A1 for the member M 1 of class Cl is 

determined as follows. 

1. A member M2 of some class C2 is found that has Ml as 
its value of member attribute A2. 

2. The value of member attribute A3 for M2 is used as 
the value of A1 for Ml. 

If A1 is a multivalued attribute, then it 
is permissible for each member of Cl to match the members of 
C2; in this case, the collection of A3 values is the value 
of attribute Al. 

Hatching permits the specification of 
binary and higher degree associations, while inversion 
permits the binary associations. The combined use of 



inversion and matching allows an SDH schema to accommodate 
relative viewpoints of an association. 

(3) Derivation . SDH provides the ability to 
define an attribute whose value is calculated from other 
information in the database. Such an attribute is called 
derived, and the specification of its computation is its 
associated derivation. The following rules are formulated by 
HAHHEB and HcLOED, in order to allow the use of derivations 
while avoiding the danger of inconsistent attribute 
specifications, 

1. Every attribute may or may not have an inverse; if it 
does, the inverse must be defined consistently with 
the attribute. 

2. Every member attribute A1 satisfies one of the 
following cases; 

1. A1 has exactly one derivation. In this case, the 
value A1 is completely specified by the derivation. 
The inverse of A1, if it exists, may not have a 
derivation or matching specification. 

2. A1 has exactly one matching specification. In this 
case, the value of A1 is completely specified by its 
relationships with an entity to which it is matched. 
The inverse of A1, if it exists, may not have a 
derivation. 

3. A1 has either a matching specification or a 
derivation. In this case, it may be that the inverse 
of A1 has a matching specif ica tion or a derivation; 
if so, then one of the above two rules applies. 

D. ADVABTAGES OF SDH 

1 . SDH provides an effective base for accommodating the 
evolution of the content structure and use of a 
database. Relativism, logical redundancy, and derived 



iflformation support this natural evolution of 
schemata. 

2. SDM supports a basic methodology that can guide the 
Database Administrator (DBA) in the design process by 
providing him with a set of natural design templates. 
The DBA can approach the application in guestion with 
the intent of identifying its classes, subclasses, 
and so on. Then he can select representations for 
these constructs. 

3. It provides a facility for expressing meaning abcut 
the data in the database. During logical database 
design, the designer needs such a facility to avoid 
confusion and to document learning, design decisions, 
and constraints. SDM provides better facilities for 
such documentation than other data models. 

4. It allows data to be described in context. Users see 
data from different perspectives. 

5. In SDH, constraints on operational data car be 
defined. For example, if a given item is not 
changeable, SDK allows this fact to be stated. 

6. An SDM schema for a database can serve as a readable 
description of its contents, organized in terms that 
a user is dihely to be able to comprehend and 
identify. 
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7. 5EH AHTI C DESIGN OF IN7ENT 0RY DATAB ASE 



Figures 5.2, 5.3, 5.4, 5.5, 5.6 and 5.7 describe the 
logical schema of the inventory database. There are five 
records in the logical schema. IDENTIFICATION record gives 
all the information about a given item in the Air Force 
inventory such as national stock number, document which 
provides technical information about the item, total 
quantity in the inventory, total amount used in the past, 
maximum authorized quantity to keep in the inventory, who is 
authorized to use, depot in which item is stocked, total 
number of the item used by units, supplier name who supplies 
item, and amount purchased in the past. The second record is 
DNIT which provides information about units in which an item 
is used. It has several fields such as unit code, superior 
command, national stcck number of item which is used in the 
unit, quantity on hand, used amount, required amount, 
location of unit and subordinate command. The third record 
is the ORDER. This record describes the ordering process of 
the item. Supplier name, Nsn_no, date, amount and shipment 
type are the member attributes of the ORDER. The fourth 
record is DEP0T_ST0CK_LE7EL which provides data about stock 
status of the item. Its fields are depo_id, 
Nsn_no_registered, stock_amount, and supplier name. The 
SUPPLIER record provides data about suppliers who supply the 
items to the Air Force. Supplier name, country, city and 
address are the member attributes of the SUPPLIER. 

In the logical schema of the inventory database all 
classes and their member attributes are informally defined 
and special remarks are written. The purpose of this process 
is to present the semantic of the database which will let 
the user easily understand the database. Figure 5.1 shows 
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the general structure of the records and the member 
attribute interrelationships. As mentioned in the previous 
chapter SDH provides three facilities for defining 
relationships. All three facilities use the SDH 
characteristic that entities can be contained within 
entities. Derivation, inverse, and match facilities are 
discussed in Chapter 5. 

In the IDENTIFICATION record there is a derivation 
between Tot_used_in_past and and Sum_of_used_Units. This 
means that To t_used_in_past is derived from 

Sum_of-used_Dnits by summation as specified. Also there is 
match between past_amount_purchased of IDENTIFICATION class 
and amount of ORDER class. This means that when the order 
occured, the value of this member will move the 
past_amount_purchased of IDENTIFICATION. On the class 
level, a member of IDENTIFICATION is to be matched with a 
member of ORDER. This is physically meaningful as well as 
logically. When the logistic department ordered an item and 
receives this order, this value should be moved to the 
past_amount_purchased in order to keep the correct data. For 
this reason, the member in the IDENTIFICATION class must 
match the value in the amount of the ORDER. Otherwise there 
can be an inconsiste tcy in the database. 

There are three inverse relationships in the logical 
schema. First, between aut_to_use of IDENTIFICATICN class 
and Nsn_no_use of UNIT class, secondly between 
depot_of-registry of IDENTIFICATION class and 

Nsn_no_registered of DEPOT_STOCK_LEVEL class, and third 
between superior_comm of UNIT class and subordi nate_ccmm of 
UNIT class. The logic is the same for all. The inverse 
facility causes two entities to be contained with each 
other. As [Ref. 4] specified, this is physically impossible, 
so this idea may seem a bit strange. Consider the first 
inverse. The attributes of IDENTIFICATION and UNIT are 
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inverses of each other. In IDENTIFICATION, the attribute 
aut_to_use has the value class ONIT and the inverse 
attribute Nsn_no_use. In the DNIT, the attribute Nsn_no_use 
has the value class IDENTIFICATION and inverse attribute 
aut_to_use. As menticned in the previous chapter, inverses 
are always specified by such pairs. In the second inverse, 
depot_of _registry cf IDENTIFICATION has the value class 
DEPOI_STCCK_LEVEL and inverse attribute Nsn_no_registry ; 
Nsn_nc_registry of DEPOT_STOCK_LEVEL has the value class 
IDENTIFICATION and inverse attribute depot_of_registry. 

It is also possible in the SDH to define an inverse 
relationship between two attributes which are in the same 
class. This case occurrs in UNIT class. Super ior_co mm and 

subor dinate-co mm are the inverse of each other. Both of them 
have the same value class, UNIT. Here, the inverse 
interattribute relationship is specified symmetrically. 
Super icr_command ccmmands the subordinate_command and 
subordinate_command is commanded by the superior_command. 
Users can describe the data in a manner which fits their 
logical view. 
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Figure 5.1 



Interclass Relationships of SDH Design. 
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lEENIIFICATION 



Description : Overall information about a given 
item which is in the Air Force 
inventory 

Member attributes: 

Nsn_no 

description:National stock number of a given 
item. 

value class: NATIONAL_STOCK_NOMBER 

mandatory 

not changeable 

Document 

descripticn; Technical Order[TO] for a aiven 
item. It specifies technical 
information about item{s) . 
value class: DOCDMENTATION 
mandatory 

Tot_Qty_on_Hand 

description: It specifies quantity which is 
currently available ror a given 
item in the Air Force (AF) logistics 
system. 

value class:QDANTITY_ON_HAND 
mandatory 

Tot_Dsed_In_Past 

descripticn: Total amount which is used in the 

? ast . 

OTAL USED IN PAST 
derivation :Sum oT usen_OlfITS 

Max_Auth_Qty_On_Hand 

Description: Maximum number of items that AF 

logistics department authorized to 
hold, not more than this capacity, 
value class: MAX_AUTH_CAPACITY 
mandatory 

Auth_to_use 

Descripticn:It specifies the unit that are 
authorized to use given item, 
value class:UNIT 
mandatory 
multival ued 

inverse :Nsn No Use 




Figure 5.2 Identification Entity Class. 
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T 



Depot_of_R€oistry 

Descripticn:Specifies the depot in which item 
is registered. 

value class:DEPOT_STOCK_LEVEL 

mandatory 

multivalued 

inverse : Nsn_No_Eegistered 
Supplier_Name 

Descripticn: Supplier name that supplies the 
item (s). 

value class:SUPPLIIS_NAMES 

mandatory 

multivalued 

Past_A mo unt_Pur chased 

Description; It specifies an amount that is 
purchased in the past, 
value class: PAST_AMODNT PURCHASED 
match ; Amount of ORDER 

Sum_of_Used_UNITS 

value class; TOTAL_DSED_IN_PAST 
mandatory 

identifier; 

Nsn_No + Document + Depot_of_registry 



Figure 5.3 



(cont’d.) . 



UNIT 

Description: All units in the Air Force that are use 
the item which are in the AF inventory. 

member attributes: 

Dnit_Code 

value class: UNIT 

mandatory 

not changeable 

Superior_Coiitt 

descripticn:The unit which has command and 
control of this unit, 
value class:UNIT 
mandatory 

inverse :Subor dinate_Comm 

Nsn_NO_Ose 

description:National stock number that are used 
in the unit fs) . 
value class:IDENTIFICATION 
inverse :Auth_to_Dse 

Qty_On_Hand 

value class:QUANTITY_ON_HAND 
T3sed_Amount 

description: Number of items that are previously 
used in the unit, 
value class:TOTAL_OSED_IN_PAST 

Reg Amount 

descripticn:Specified number of items are 

required in the unit for operational 
]T0Qdd.Il€SS • 

value class:EEQOIRED_iMOONT_IN_UNIT 
Location 

description: Location of unit in geographical 
coordinate system, 
value class:LOCATIONS 

Subordinate^Coram 

value class:DNIT 
inverse : Superior_Comm 

identifier: 

Unit Code + Nsn-No Dse 



Figure 5.4 Onit Entity Class. 
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CBDEE 

Description ; Dependent up on the requests from the 
unit and depot, all ordered items by 
Department of logistics of AF. 

member attributes 

Supp_Name 

descript ion; Supplier name (s) that supplies the 
item (s) . 

value class; SDPPLIEE_NAHES 

mandatory 

not changeable 

Nsn__No 

descripticn; National stock number of item that 
is ordered to supplier (s). 
value class: NATIONAL_STOCK_NOflBER 
mandatory 

Date 

descripticn:Date of order 
value cl ass; DAT IS 
mandatory 

Amount 

descript icn: ordered amount for a given item, 
value class;ORDERED_AMODNT 

Ship me nt_type 

value class;SHIPflENT 
multivalued 

identifier; 

Nsn N o 



Figure 5.5 Order Entity Class. 



DEP01_ST0CK_LEVEI 

description: Picvides information about stock level 
of a given item in the depot. 

member attributes 

Depo_ID 

value class: DEPOT ID 
mandatory ” 

not changeable 

Nsn_No_Eegister 

description: Differ ent groups of items are 

registered into different depots 
such as communication items and 
weapon items are stored into 
different depots. This attribute 
specifies registered item into 
depot. 

value class:IDENTIFICATION 
mandatory 

inverse : Depot_cf_Registry 

Stock_Amount 

description: Number of items that are currently 
available as stock in the depot, 
value class:STOCK_STATUS 

Supplier name 

value class:SUPPLIEE_NAME 

identifier : 

Ns_No_Register + Depo_ID 



Figure 5.6 Order Entity Class. 
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SDPEIIEE 

description; All suppliers that are currently supply 
items to the AF 

member attributes; 

Supp_Name 

value class:SUPPLIEE_NAME 
Country 

descript ion; Country of supplier(s) that is/are 
currently supply (ies) item Is) . 
value classrCOONTEY 
mandatory 
multival ued 

City 

descript ion; Supplier location as city. 

value class;CITlES 

multivalued 

Address 

description; Address of supplier that supplies 
part. 

value class; aDDEESSES 
identifier 
Supp_N ame 



Figure 5-7 Supplier Entity Class- 
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NA‘riONAI_STOCK_NDMEEE 

interclass connection; subclass of STRING where it has 
13 numbers which are divided into four (4) groups: 
3020-00-001-0072 

DOCDMENTATION 

interclass connection ; subclass of STRING where speci- 
fied format. 

QDANTITY_OH_HAND 

interclass connection ; subclass of STRING where format 
is positive integers. 

TOTAl OSED IN PAST 

in'^erclass”connection : subclass of STRING where format 
is positive integers. 

MAX_ AUTHORIZE B_ CAPACITY 

xnterclass connection: subclass of STRING where format 
positive integers. 

AUTHORIZED_TO_OSE 

interclass connection : subclass of STRING where format 
is five (5) characters 

DEFO_Or._REGISTRY 

interclass connection ; subclass of STRING where format 
is five (5) characters 

SUPPLIER_NAME 

interclass connection; subclass of STRING where format 
is two (2) characters 

PAST_AMCDNT_PURCHASED 

interclass connection; subclass of STRING where format 
is positive integers. 

UNIT 

interclass connection;subclass of STRING where speci- 
fied. 

USED_AHOUNT_IN_DNIT 

interclass connection; subclass of STRING where format 
is positive integers. 

RECUE£T_AHOUNT_IN_UNIT 

interclass connection; subclass of STRING where format 
is positive integers. 

LCCATICN_OF_UNIT 

interclass connection: subclass of STRING where speci- 
fied. 



Figure 5.8 Domain of Attributes. 
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DATES 

interclass connection ; subclass of STRING where format 
is : 

month : number where =>1 and <=12 

«i /II 

dajj ; number where integer and =>1 and <=31 

year ; number where integer and =>1900 and <=2000 

where jf if ( month=4 or =5 or =9 or =11 ) then 

day <=j 0 1 and if ( month=2 then day<=29 ) 
ordering by year/month, day. 

OEEEE AMOUNT 

interclass connection; subclass of STRING where format 
is positive integers. 

SHIEMENT 

interclass connection;subclass of STRING where speci- 
fied. 



DEEOT ID 

interclass connection; subclass of STRING where speci- 
fied. 

STOCK STATUS 

interclass connection; subclass of STRING where speci- 
fied. 



COUNTRY 

interclass connection; subclass of STRING where speci- 
fied. 

ADDRESSES 

interclass connection; subclass of STRING where speci- 
fied. 

CITY 

interclass connection; subclass of STRING where speci- 
fied. 



Figure 5. 9 



(cont *d) 



VI. RELATIO NAL H ODEL 



The relational model was introduced to the database 
communitj by E.F. Codd (1970). This innovation stressed the 
independence of the relational representation from physical 
computer implementation such as ordering on physical 
devices, indexing, and using physical access paths. The 
model thus formalized the separation of the user view of 
data frcm its eventual implementation; it was the first 
model to do so. In addition, Codd proposed criteria for 
logically structuring relational databases and 
implementation-independent languages to operate on those 
databases. There have been many further developments in its 
theory and application. Relational design procedures have 
also received considerable attention in the last few years. 
P.A. Bernstein (1976) had proposed synthesizing relations 
from functional dependencies, and Fagin’s work in 1977 then 
drew attention to the decomposition approach to design. 

A. BASIC STEDCTDEE OF THE RELATIONAL HODEL 

Usefulness of the relational model in data analysis can 
be measured by considering several objectives. To meet the 
first objective- identify user requirements- the model must 
serve as a communication medium between the users and the 
computer personnel, giving them an interface that can be 
clearly and unambiguously understood. The independence of 
this interface from computer implementation is of the utmost 
importance. The relational model uses tables to provide this 
interface. The tabular representation of relations satisfies 
the first objective of data analysis. The second objective, 
the conversion to physical implementation, is also satisfied 
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by the relational model. One obvious approach is to directly 
implement the relational model on a machine. To do this a 
DBMS that supports the relational model must be available on 
the computer system. A particular set of relations can then 
be directly declared by using the definitional language 
provided by the system. Direct conversion was not feasible 
when the relational model was first proposed by Codd in 
1971, but today direct conversion from a relational 
specification to physical implementation is becoming 
increasingly possible. The third objective deals with the 
following criteria for logical data structures: 

1 . Each fact should be stored once in the database 

2. The database should be consistent following database 
operation 

3. The database should be resilient to change. 

The first criterion not only removes storage redundancy 
but also improves database consistency. If the same fact is 
stored twice, it is possible that during execution of a 
complex operation, cnly one of the copy will be updated. 
The database then becomes inconsistent. In an inconsistent 
database, it is possible to get different database outputs 
for the same fact, thus creating a reliability problem. The 
second criterion requires that the database be consistent at 
all times. The third criterion deals with a different 
aspect. It is a consequence of the environment in which the 
database exists. This environment is usually in a state of 
constant change; consequently, the database must be 
continually redesigned to meet continually changing user 
requirements. 

1 . Terminology 

Informally, a database is made up of any number of 
relations. A relation is simply a two-dimensional table that 
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has several properties. First, the entries in the tables are 
single-valued; neither repeating groups nor arrays are 
allowed. Gelations are flat files. Second, the entries in 
any cclumn are all of the same kind. Columns of a relation 
are referred to as attributes. Finally, no two rows in the 
table are identical in all attribute values and the order of 
the rows is insignificant. Figure 6.1 shows an example of a 
relation. 



IDENTIFICATION 












NUN 


FICHE-NO 


FRAME-NO 


ITEH-NO 


— >Attribute 




233 5-00-679-0033 


001 


LIO 


05 


— >Tuple 




2835-00-682-5360 


001 


A10 


05 


— >Tuple 




2345-00-680-9876 


002 


B77 


08 


— >Tuple 












j 



Figure 6,1 A Sample Relation Form, 

Each row of the relation is known as a tuple. If the 
relation has n columns, then each row is referred to as an 
n-tuple. Also, a relation that has n columns or n 
attributes is said to be of degree n. Each attribute has a 

domain, which is a set of values that the attribute can 

have. Fcr example, in figure 6.1 the domain of the item-no 
is all positive integers less than 100. Sometimes it is 
possible that the domains of two attributes can be the same, 
lo differentiate between attributes that have the same 

domain, each is a given a unique attribute name. The 

generalized format: 
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EELATICN NAME {attribute name, attribute name,....) 

IDENTIFICATION ( NIIN, FICHE-NO, FEAHE-NO, ITEM-NO ) , 
is called the relation structure. If we add constraints 
on allowable data values to the relation structure, we 
then have a relational, schema [ref. 6]. 

a. Keys of Eelations 

The hey is the attribute or set of attributes 
that uniguely identify tuples in a relation. A relation key 
is formally defined as a set of one or more relation 
attributes concatenated so that the following three 
properties hold for all time and for any instance of the 
relation : 

1. Unigueness: The set of attributes takes on a unigue 

value in the relation for each tuple. 

2. Nonredundancy: If an attribute is removed from the 

set of attributes, the remaining attributes do not 
possess the unigue property. 

3. Validity: No attribute in the key may be null. 

It is possible for relations to have more than 
one relation key; each key is made up of a different set of 
attributes. The relation key is often called the candidate 
key. If a candidate key is the only key of the relation, it 
is generally referred to as primary key. When an attribute 
in one relation is a bey of another relation, the attribute 
is called a foreign key. Foreign keys are important when 

defining constraints across relations. A prime attribute is 
an attribute that is part of at least one candidate key. A 
nonprime attribute is not part of any candidate key. 

2 . Consis tenc v 

The goal of relational design is to choose the 
relations that preserve consistency following database 
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operations and that store each fact at most once in the 
database. Relations that do this are said to be in normal 
form. In nonnormal relations, anomalies can arise after 
database tuple operation. The three tuple database 
operations are as follows; 

1. ADD TOPLZ ( relation name, <attribute nam€> ) . 
This operation adds a new tuple to a relation. The attribute 
values of the tuple are given as part of the operation. For 
example : 

add tuple (identification, <2835-00-678-4520, 00 1 ,B01 ,05>) 
would add a new row to the relation in Figure 6.1. An 
add-tuple operation will not be allowed if it duplicates a 
relation key. 

2. DELETE TDELE (relation name, <attrib ute value>) . 
This operation deletes a tuple from a relation. For example; 
delete tuple (IDENTIFICATION, <2335-00-679-0033, 001, L10,05>) 
would delete the first row from the IDENTIFICATION relation. 

3. UPDATE TUPLE (relation name, <old attribute 
values>, <new attribute values>) . This operation changes the 
tuple in the relation. For example; 

update tuple (IDENTIFICATION, <2835-00-682-5360, 001, A01, 05> , 
<2835-00-682-5360, 002, LI 1,06>) This would change FICHE-NO, 
FRAME-NO, and ITEH-NO for NIIN value equal 2835-00-682-5360. 
Any update will not be allowed if it duplicates a relation 
key . 

In a normal relational structure no anomalies . arise 
after the application of any one of the three preceding 
operations with any set of attributes values. 

3 • Fu ncti onal Dep endenc y 

Functional dependency [ FD ] is terra derived from 
mathematical theory; it concerns the dependency of values of 
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one attribute or set of attributes on those of another 
attribute or set of attributes. Formally, a set of 
attributes X is functionally dependent on a set' of 
attributes Y if a given set of values for each attribute in 
Y determines a unique value for the set of attributes in X. 
The notation Y — >X is often used to denote that X is 
functionally dependent on Y. Sometimes Y is called a 
determinant of the FD Y — >X. In the simplest case, both X 
and Y are made up of one attribute as shown in Figure 6.2. 



- 




NIIN 


> 


FICHE-NO 















Figure 6.2 Functional Dependency Diagram. 

It is also possible to have two attributes that are 
functionally dependent on each other. It is important to 
realize that functional dependency is a property of the 
information that is represented by relations. That is, 
functional dependency is not determined by the us€ of 
attributes in the relations or by the current contents of a 
relation. 

Given a functional dependency Y — >X (where X and Y 
are both sets of attributes) , a unique value for each 
attribute in X is determined only when the values for Y 
attributes are known. However, it is possible that values of 
X can be uniquely determined by only a subset of the 
attributes of Y. The term full functional dependency is used 
to indicate the minimum set of attributes in a determinant 



of an ID. Formally a set of attributes X are fully 
functionally dependent on a set of attributes Y if 

1. X is functionally dependent on Y. 

2. X is not functionally dependent on any subset of Y. 

like functional dependency, full functional 
dependency is a property of the information that is 
represented by the relation. 

4 . Normal Forms 

ihen determining whether a particular relation is in 
normal form, we should examine the FDs between the 

attributes in the relation. In the notation first proposed 
by C. Beeri and co- workers (1978), the relation is defined 
as made up of two components: the attributes and the FDs 

between them. El = ( {X,Y,Z}, { X — >Y , X — >Z } ) The first 

component of the relations is the attributes, and second 
component is the FDs. For example, 

IDENTIFICATION = ( {NIIN, FICHE-NO, FEANE-HO, ITEM-NO) , 

{NUN— >FICHE-NO , NUN — >FRAME-NO , NIIN — >ITEM-NO) ) 

The functional dependencies between attributes in a relation 
are obviously important when determining the relation's key. 

There are a number of normal forms as shown in 
Figure 6.3. Relations are in first normal form (INF) if all 
domains are simple. In other words all legitimate relations 
are in INF. 

A relation is normalized by replacing the nonsimple 
domains with simple domains. A relation R is in second 
normal form (2NF) if every nonprime attribute of R is fully 
functionally dependent on each relation key. 

A relation R is in third normal form if it has the 
following properties: 

1. The relation E is in second normal form, and 
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Universe of relations (normalized and unnormalized) 



INF relation (normalized relation) 



2NF relation 



3NF relation 



BCNf relation 



4NF relation 

5NF fellTETon 



* BK/NF j 



Figure 6.3 Normal Forms. 

2. The nonprime attributes are mutually independent; 
that is, it has no transitive dependency. 

In other words, a relation R is in third normal form 
(3NF) if and only if it is in 2NF and every nonprime 
attribute is nontransitively dependent on the primary key. 
For example, suppose 
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R = ( {AE— >C, C — >D} ) AB is primary key. 

AB — >C C — >D by transitivity AB — >D hence relation R is 

not in 3NF, because^ there is a transitivity between 
nonprime attributes. 

In the definition of the third normal form we 
assumed that the relation had only one relation key. 
Problems arise with the definition when applied to relations 
that have more than one relation key. The original 
definition of 3NF was modified by a stronger definition 
which was proposed by Boyce and Codd. It is known as BCRF. A 
relation R is in BCNF (Boyce/Codd Normal Form) if and only 
if every determinant is candidate key. For example, suppose 

R = { {A,B,D,E} , {A — >BED , D— >A} ) Here relation R will 

be in BCNF if both A and D are keys of R. Formally, 
multivalued dependency is defined as follows; in relation 
R(X,Y,Z), X === > Y if each X value is associated with a set 
of Y values in a way that does not dependent on Z values. 

A relation is in 4NF if it is in BCNF and has no 
multivalued dependencies. This definition means that if a 
relation has multivalued dependency and is in 4NF, then the 
multivalued dependencies have a single value. In others 
words, all independent attributes have single value. 

A relation is in 5NF if and only if every join 
dependency in a relation R is implied by the candidate keys 
of relation R. 

A relation is in Domain-Key normal form (DK/NF) if 
every constraint on the relation is a logical consequence of 
the definition of the keys and domains. A constraint is any 
rule on the static value of the attributes that is precise 
enough that we can evaluate whether or not it is true. 
Examples of the constraints are inter-relation constraints, 
functional dependencies, multivalued dependencies, and join 
dependencies. DK/NF means that if we can define keys and 
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domains in such a way that all constraints will be 
satisfied, then mcdification anomalies are impossible. 
Unfortunately, there is no known way to convert a relation 
to DK/NF automatically, nor it is even known which relations 
can be converted to DK/NF. In spite of this, DK/NF can be 
exceedingly useful for practical database design. 

B. ADVANTAGES AND DISADVANTAGES OF RELATIONAL MODELS 
^ Advantages 

a. Simplicity 

The end user is presented with a simple data 
model. User requests are formulated in terms of the 
information content and do not reflect any complexities due 
to system-orient ed aspects. A relational data model is what 
the user sees, it is not necessarily what will be 
implemented physicallypRef.il]. 

b. Nonprocedural Request 

Because there is no positional dependency 
between the relations, requests do not have to reflect any 
preferred structure and therefore can be nonprocedural. 

c. Data Independence 

This should be one of the major objectives of 
any database management system. The relational data model 
removes the details of the storage structure and access 
strategy from the user interface. The relational model 
provides a relatively higher degree of data independence 
than do network and hierarchical models. However, the design 
of the relations must be complete and accurate for making 
use of this property of the relational model. 
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d. Theoretical Foundation 



The relational data model is based on -the 
well- developed mathematical theory of relations. The 
rigorous method of designing a database using normalization 
gives this model a solid foundation. This kind of foundation 
does not exist for the other two models. 

2 - Dis advantage s 

A disadvantage sometimes cited for a relational 
model is machine performance. With present-day hardware the 
JOIN operation is likely to take substantial machine time. 
It is feasible with small relations, but some commercial 
files are hundreds of millions of bytes long. In 
understanding the performance issue, it is very important to 
remember that the relations and the operations on them such 
as the JOIN will never occur physically. Instead, equivalent 
results will be produced by means of pointer structures or 
indices. It appears tcday that technological improvements in 
providing faster and more reliable hardware nay solve this 
problem . 
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VII. EEIATIOH ai DATAB ASE DESIGN 

The relational model is attractive in the database 
design because it provides formal criteria for logical 
structure, namely, normal form relations. The problem, then, 
is to choose a design procedure to produce normal form 
relations. Two different approaches have been proposed: 

1. Decomposition procedures: These commence with a set 

of one or more relations and decompose ncnncrmal 
relations in this set into normal forms. 

2. Synthesis procedures: These commence with a set of 

functional dependencies and use them to construct 
normal form relations. 

Host designs commence with an information gathering 
phase in which a set of data elements and FDs between them 
are identified. The information is then used to produce 
normal relations. On the other hand, one could conceive of a 
procedure where all the data attributes are considered to 
form cne relation, which is then decomposed in sutseguent 
design steps. 

A. EEIATIONAL DESIGN CBITEBIA 

Beeri and co-workers (1978) have identified three 
relational design criteria: 

1. SEPARATION: The original specif ications are separated 
into relations that satisfy certain conditions. 

2. REPRESENTATION: The final structure must correctly 

represent the original specif ications. 

3. REDUNDANCY: The final structure must not contain any 

redundant information. 
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The separatioa criteria is that the database must be 
separated into a number of normal relations. The other two 
criteria are relatively general. In specific terms each can 
be applied to attributes, FDs, or data. Here, criteria will 
be defined more specifically. For example, given the 
relation E = (£A,B,C) , £A — > B , A — > C} ) . 

Here E comprises three attributes, A , B, and C. Ihe 

functional dependency between these attributes are A — >E and 
A — >C. The notation used to describe the input and output of 
the design process is Sin and Sout. Sin and Sout are sets of 
relations. Here Sin is the input to the design process and 
Sout is the output of the design process. 

1 . Eepresentati cn Criteri a 

One goal of any design process is to produce an 
output design, Sout, to accurately represent Sin. All the 
relations in Sout must satisfy the conditions for normal 
form. Eeeri and co-workers (1978) have defined three 
representation criteria for the representation of Sin by 
Sout ; 

1. EEP1; The relations Sout contain the same attributes 
as Sin. 

2. EEP2: The relations Sout contain the same attributes 

and the same IDs as Sin. 

3. EEP3: The relations in Sout contain the same 

attributes and the same data as Sin. 

EEPI requires all the attributes in Sin to also 
appear in the relations in Sout. But it does not consider 
any dependencies between the attributes. According to EEP2 
Sin will contain a set of attributes and a set of functional 
dependencies. Sout will also contain a set of attributes and 
a set of FDs. Representation EEP2 requires that each ID in 
Sin be either: 

1. Contained as an FD in one of the relations in Sout or 
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2. Derived from the FDs in the relations in Sout, using 
the FD inference rules. For example in Figure 7. 1, 

Sin = ({A,B,C} , £ A —> B , C — > B }) and 

Sout = (R2,R3) where R2=({A,B},{A — >B}) and 

R3=(£B,C}, £C— >B}). 

Thus R2 and R3 constitute the decomposition by 
projection of Sin. Each of the functional dependencies in 
Sin is contained in Sout; hence we can say that Sout is a 
REP2 representation of Sin. It is interesting that Figure 
7.2 shows a decomposition that is not a REP2 representation 
of Sin[R€f.10]. 

Figure 7.1 includes a relation R1 that is decomposed 
by projection into twc relations, R2 and R3, in Sout. Note 
that R2 and R3 do not contain the same information as Sin 
since different responses are obtained to the same question 
applied to Sin and Sout. Hence Sout is not an REP3 
representation of Sin. Because if we ask: To what c is a1 

related? In Sin the answer is £c1} ; in Sout the answer is 
{c1,c2}. This join in Figure 7.1, contains additional tuples 
to those of Sin and is sometimes known as a CROSS JOIN. Note 
that in Figure 7.2 the two relations Y1 and Y2 in Sin are an 
REP3 representation of Sin because their join contains 
exactly the same tuple as in the original relation, R. 

2 - l ossle ss De composition 

Formally, a lossless decomposition can be described 
as follows. The deccnposition of a relation R(X,Y,Z) into 
relations Rl and R2 is defined by two projections: R1 = 

projection of R over X,Y and R2 = projection of R over X,Z 
where X is the set of common attribures in Rl and R2. The 
decomposition is lossless if E = join of El and R2 over X. 
The decomposition is lossly if R is a subset of the Join of 
El and E2 over X. 




Figure 7. 1 Decomposition. 
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Figure 7.2 Decomposition 



CCNDITIONS; The decomposition of E(X,Y,Z) in B1(X,Y) 
and R2(X,Z) is lossless if for attribute X, common to both 
El and E2, either X — >Y or X — >Z. Thus in figure 7. 1 the 

common attribute of E2 and R3 is B, but either B — >A or 
E — >C is true, hence decomposition is lossly. In Figure 7.2 
the common attribute of Y1 and Y2 is X, both X — >Y and X-->Z 
is true, hence decomposition is lossless. 

3 . Redundancy C riteria 

Redundancy can be defined in various ways. One set 
of redundancy criteria is as follows [Ref. 7]; 

1. REDl : a relation in Sout is redundant if its 

attributes are contained in the other relations in 
Scut. 

2. RED2 : A relation in Sout is redundant if its FDs are 
the same or can be derived from the FDs in the other 
relations in Scut. 

3. EED3 : A relation in Sout is redundant if its content 
can be derived from the contents of other relations 
in Sout. 

EED1 is not a powerful criterion, because during 
separation it is often necessary to create separate 

relations that represent FDs between attributes, which may 
appear in other relations. RED2 and RED3 can be quite useful 
criteria. Any design algorithms should in particular avoid 
EED3 because it would keep the same data in more than one 
relation. Such relations could all be in normal form and no 
anomalies would occur in relations. But, interrelation 
anomalies would arise if the same fact were updated in one 
relation but not the other. RED2 would cause the same 
problem. 
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B. EElflTICHAL DESIGB PfiOCEDOEE 



It is interesting to note that in Figure 7. 1 the design 
Sout is on BEP2 but not on EEP3 representation of Sin 
whereas in Figure 7.2 the design Sout is on REP3 but not on 
EEP2 representation of Sin. This situation creates prchlems 
of relational research; namely, to find a design procedure 
that yields an Sout that is both on EEP2 and REPS 
representation of Sin. Similarly, design procedures should 
aim to reduce redundancy, but here again different design 
procedures can result in either RED2 or REDS representations 
of Sin [Eef.8]. 

There are two classes of algorithms; decomposition and 
synthesis. Decomposition algorithms commence with one 

relation and successively decompose it into normal form 
relations. The concepts of 3HF and BCNF are not sufficient 
for decomposition algorithms, so the ideas of multivalued 
dependency and a 4NF have to be introduced. 

Synthesis algorithms use FDs to produce normal form 
relations. For these algorithms to be successful it is 
necessary to ensure that: 

1. FDs in Sin correctly represent user semantics, 

2. Algorithms can be devised to produce relations in 
Sout that correctly and nonredundantly represent Sin. 

If synthesis algorithms are to be effective, their input 
must describe those nonfunctional relationships that cannot 
be expressed as FDs between attributes. Perhaps the 
best-known synthesis algorithm is the one devised by 
Bernstein. It is premised on grouping all FDs with the same 
determinant and constructing a relation for each such group. 
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C. PHYSICAL DESIGH CJ INVENTOBI DATABASE 



1 . M apping from into Belational Model 

Ihe logical design of the inventory database cannot 
be used as the physical design of a relational database. Por 
example, in the IDENTIFICATION and DNIT records, there are 
some multivalued attributes which are not allowed in a 
relation. The relations must be transformed so that each 
attribute has only one value per tuple. Also, the logical 
design in Chapter 5 allows tuples to be contained in ether 
tuples which cannot be done physically. Relations in the 
logical design have to be redefined to eliminate this 
problem . 

Consider the relations UNIT and IDENTIFICATICN. 
Actually, Auth__to__use of IDENTIFICATION is a collection of 
tuples representing DNIT which are using a specified item. 
We can eliminate Auth_to_use of IDENTIFICATION, because, 
whenever we need this information we can get it by use of 
the Data Manipulation Language (DML) . It is possible to 
construct contained tuples by DML joins. In this case, 
Auth_to_use will be constructed and not stored. 

The process just described can be used to transform 
the logical schema into a relational schema. All contained 
tuples have been replaced using the same logic. Auth_tc_use 
of IDENTIFICATION is deleted and interrelation constraints 
are added. Similarly, Depot_of_registry of IDENTIFICATION 
and Subordinate_comm of UNIT and Past_amount_purchased of 
IDENTIFICATION are deleted and interrelation constraints are 
added . 

The resulting design is shown in Figure 7.3 and 7.4. 
Figure 7.3 shows relation, attributes, and interrelation 
constraints, and Figure 7.4 shows the domains and 
attribute-doma in cor respondences. 



74 



PAET-IDENTIFICATICN (Nsn_No,Tot Qty-On Hand, 

Sum of used unit,dax Auth Qty Hand) 
KEY"; Hsn no _ _ _ 



DOCDMENT IDENTIFICATION (Nsn No, Document, Supp name) 

KEY : Nsn No " 



0NIT_IN7ENT0EY (Onit_Code, Nsn_No_Ose, Qty_On_Hand, 

Ds€d_amount, Eeg_amount) 

KEY ; Unit Code + Nsn no Use 



UNIT ID (Unit Code, Superior Comm, Location) 
" KEY :"Unit Code 



OEDEE (Nsn_no, Supp name, Date, amount, Ship Type) 
KEY ; Nsn no" 



DEPOT_STOCK_1EVEL (Eepo Id,S tock_amount, Supp_name, 

Ksn No Begistry) 

KEY T Depo ID 



SDFELIEE (Supp name , Country, Address, City) 
KEY :"Supp_name 



Figure 7.3 Eecords of fielational Schema. 
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Figure 7.fl Attributes and Domains. 
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VIII, SYSTEM B: REL ATIONAL AP PROACH ^ DAT ABASE MABAGEBE NT 

System E is a database management system which provides 
a high level relational data interface. The system provides 
a high level of data independence by isolating the end-user 
as much as possible from underlying storage structures. The 
system permits definition of a varity of relational views on 
common underlying data. Data control features are provided, 
including authorization, integrity assertions, triggered 
transactions, a legging and recovery subsystem, and 
facilities for maintaining data consistency in a 
shared-update environment. System R supports a relational 
database, i.e., a database in which all data is perceived by 
users in the form of tables. All access to this database is 
via a data sublanguage called SEQDEL. 

A. ABCHITECTDEE AND SYSTEM STiOCTORE 

Eigure 8.1 gives a functional view of the system 
including its major components and interfaces. The 
Relational Storage Interface (ESI) is an interface which 
handles access to single tuples of base relations. 

This interface and its supporting system, the Relational 
Storage System (RSS) , is actually a complete storage system 
in that it manages devices, space allocation, storage 
buffer, transaction consistency and locking, deadlock 
detection, backout, transaction recovery, and system 
recovery. Also it maintains indices on selected fields of 
base relations and pointer chains across relations.. 

The Relational Data Interface {RDI) is the external 
interface which can be called directly from a programming 
language, or used to support various emulators and other 
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< Programs to support- 

varxous interface: 
Stand-alone SECOEI 
Query By Exampleretc. 



< Relational Data 

Interface ( RDI ) 



< Relational Storage 

Interface ( RSS ) 



Figure 8- 1 Architecture of System H. 

interfaces. The Relational Data System (RDS) , which supports 
the EDI, provides authorization, integrity enforcement, and 
support for alternative views of data. The high level SEQUEL 
language is embedded within the EDI and is used as the basis 
for all data definition and manipulation. In addition, the 
EDS maintains the catalogs of external names, since the ESS 
uses only system generated internal names. The RDS contains 
an optimizer which chooses an appropriate access path for 
any given request frcn; among the paths supported by the RSS. 
RSS and EDS will be evaluated in detail the following next 
two sections. 

B. THE EELATI05AL DATA SYSTEM 

The Relational Data Interface (HDl) is the principal 
external interface of. System R. The data definition 
facilities of the EDI allow a variety of alternative 
relational views to he defined on common underlying data. 
The EDS is the subsystem which implements the RDI. The RDI 
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consist^ of a set of operators which may be called from PL/I 
or other host programming languages. All facilities of the 
SEQOEL data sublanguage are available at the RDI by means of 
the EDI-called SEQOEL. SEQOEL is designed to be used both as 
a stand-alone language for interactive users and as a data 
sublanguage embedded in a host programming language such as 
PL/I. In the latter case the SEQOEL statements in the 
program are identified by a precompiler which replaces them 
with valid PL/I calls to a run-time module which provides 
the environment for executing an application program that 
has been through the precompilation process. The 
precompilation process is described below[ Ref . 6 ] . 

1. The precompiler scans the source program and locates 
the embedded SEQOEL statements. 

2. For each statement it finds, the precompiler decides 
on a strategy for implementing that statement in 
terms of RSI operations. Having made its decisions, 
the precompiler generates machine language routines 
(including calls to the RSS) that will implement the 
chosen strategy. The set of all such routines 
together constitutes the access module for the given 
source program. The access module is itself stored in 
the database. 

3. The precompiler replaces each of the original 

embedded SEQOEL statements by an ordinary ?L/I 

statement to the run-time module of the RDS. 

The modified source program can now be compiled by the 
PL/I compiler in the normal way. This process is depicted in 
Figure 8.2. 

In terms of query facilities, SEQOEL provides extensive 
query facilities based on English key words. As a 
relational DBMS we have ORACLE in our school. In terms of 
Query facilities there is no big difference between System R 
and ORACLE. Query, data manipulation, and data definition 
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Figure 8-2 Precompilation Process. 

facilities of ORACLE v<ill be illustrated over the Inventory 
Database by a series cf examples in Chapter 9. 

1 Definit ion Facilitie s 

The primary data structure in System R is the Base 
Relation (Ease Table) . The base relation is a table that 
has its cwn independent existence and is represented in the 
physical database by a stored file. Base table can be 
created at any time by executing the SEQOEL DDL statement 
CREATE TABLE, which takes the general form: 

CREATE TABLE base-table-name 

(field-definition , ) 

{ IN SEGMENT segment-name } 
where a field-definition, in turn, takes the form 
field-name ( data-type (, NONULL } ) 

Successful execution cf the CREATE TABLE statement causes a 
new, empty base table to be created in the specific segment 
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with the specific base- table- name and specific field 
definition. The user may now proceed to enter data into that 
table using the SEQUEL INSERT statement, A System E database 
is partitioned into a set of disjoint SEGMENTS which 
provides a mechanism for controlling the allocation of 
storage and the sharing of the data among users. Any given 
base table is wholly contained within a single segment and 
indices on that base table are also contained in that same 
segment. However, a given segment may contain several base 
tables and their indices. A public segment contains shared 
data that can be simultaneously accessed by multiple users. 
A private segment contains data that can be used by only one 
user at a time. If the CREATE TABLE statement does not 
specify the segment, then the base table will go in a 
private segment belonging to the user that issued the CREATE 
TABLE. This specification is an option in the CREATE TABLE 
statement. Each field definition in CREATE TABLE includes 
three items; A field-name, a data-type for the field, and 
optionally a NONDLL specif ication. The field name has to be 
unique within the base table. The System R supports the 
concept of nonull field values. Null is a special value that 
is used to represent "value unknown” or "value 
inapplicable”. 

By using the EXPAND TABLE statement, an existing 
base table can be expanded at any time by adding a new 
column at the right ; 

EXPAND TABLE base- table-name 

ADD HELD filed-name ( data-type ) 

The important point is that the specification NONULL is not 
permitted in EXPAND TABLE. It is also possible to destroy 
an existing base table at any time: 

DROP TABLE base-table-name 

All records in the specific base table are deleted, all 
indexes and views on that table are destroyed, and the table 
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itself is then also destroyed; that is, its description is 
removed from the dictionary and its storage space is 
released[Ref . 7], 

The query power of SEQUEL may be used to define a 
view as a relation derived from one or more other base 
tables. This view may then be used in the same ways as a 
base table; queries may be written against it, other views 
may be defined on it, and in certain circumstances described 
below, it may be updated. Any SEQUEL query may be used as a 
view definition by means of a DEFINE VIEW statement; 

DEFINE VIEW view-name 

{ ( field-name , } 

AS SEIECT - statement 

Views are dynamic windows on the database as shown in Figure 
8.3. In System R, a view that is to accept updates must be 
derived from a single base table. Moreover, it must satisfy 
the fcllcwing constraints; 

1. Each distinct row of the view must correspond to a 
distinct and uniquely identifiable row of the base 
table. 

2. Each distinct column of the view must correspond to a 
distinct and uniquely identifiable column of the base 
table. If a view does satisfy constraints 1 and 2, 
then any update against it can easily be mapped into 
an update on the corresponding base table. 

There is another SEQUEL command for data definition 
facility: KEEP TABLE. It causes a temporary table to become 
permanent. Normally, temporary tables are destroyed when the 
user who created them logs off. 

2. ^ta Co ntrol Facilitie s 

System R has extensive data control facilities that 
enable users to control access to their data by other users. 
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Figure 8.3 System E as Seen by an User. 

and to exercise control over the integrity of data values. 
Ihe data control facilities have four aspects: transactions, 
authorization, integrity assertions, and triggers. 

A transaction is a series of the statements which 
the user wishes to te processed as an atomic act. The 
meaninc of the "atomic” depends on the level of consistency 
specified by the user. The user controls transactions by the 
operator BEGIN-TRANS and END-TRANS. The user may specify 
save points within a transaction by the operator SAVE. As 
long as a transaction is active, the user may block up to 
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the begiaing of the transaction or to any internal space 
point by the operator RESTORE. 

System R allows for an extremely simple method of 
authorization checking. System R maintains two tables for 
the use of the authorization subsystem; SYSAOTH and 
SYSCCIADTH. The SYSADTH table has up to two rows for each 
combination of relation (base or view) and user. The columns 
in the SYSADTH table correspond to user ID, base relation or 
view name, type (base or view) , a column for each of the 
privileges on the relation (Y OR N) and a column for grant 
option (Y or N) . For each relation on which a user is 
authorized to perform some action, there are up to two 
tuples in SYSADTH: one for grantable and the other for 
non-gran table privileges. In case the user has update rights 
on a relation, the table SYSCOLAOTH indicates precisely 
those columns of the relation on which the user has the 
update privilege. These two tables, SYSADTH and SYSCOIADHT, 
are updated whenever a new base relation or view is created 
or an authorized user executes a GRANT statement, thereby 
granting a set of pri-vileges to one or more other users. The 
two tables are referenced immediately before the execution 
of any SEQDEl statement[ Ref . 5]. 

The third important aspect of data control is that 
of integrity assertions. Any SEQDEL logical expression 
associated with a base table or view may be stated as an 
integrity assertion. At the time an assertion is made by an 
ASSERT statement, its truth is checked; if true, the 
assertion is enforced until it is explicitly dropped by a 
DROP ASSERTION statement. Any data modification by any user 
which violates an active integrity assertion is rejected. 
Assertions may apply to individual tuples or to sets of 
tuples. 

The fourth aspect of data control, triggers, is a 
generalization of the concept of assertion. A trigger causes 
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a prespecified seguence of SEQUEL statements to be executed 
whenever some triggering events occurs. The triggering event 
may be retrieval, insertion, deletion, or update of a 

particular base table or view. EDI can monitor such events 

by simply scanning a transaction for a SEQUEL statement that 
corresponds to a particular triggering event. After each of 
these statements, immediately a call statement is included 
to invoke the appropriate trigger routine. 

3. Data Ma nip u lation Statement s 

The EDI facilities for insertion, deletion, and 
update tuples are also provided via the SEQUEL data 
sublanguage. SEQUEL operates on both base tables and views. 
It can be used to manipulate either one tuple at time or a 
set of tuples with a single command. 3y using these 

facilities, it is possible to assign the result cf a query 
to newly created relation. 

An insertion statement in SEQUEL may provide only 
some of the values for the new tuple, specifying the names 
of the field which are provided. Fields which are not 
provided are set to the null value. The physical position of 
the new tuple in storage is influenced by the "clustering’* 
specification made on associated ESS access paths. 

Eeletion is done by means of a DELETE statement 
accompanied by a WHIBE clause. The WHEEE clause specifies 
the conditions that must be satisfied by the records to be 
deleted. The EDI can translate the UPDATE statements in one 
of two ways: 

1. By using the EETEIEVE command to determine the 

addresses of the selected records, and then using the 
EEPLACE command to modify these records one at a 
time. 

2. By using the EEPLACE command to modify all the 

selected records simultaneously. 
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Which of these two methods is to be used depends on 
the actual SEQUEL statement. If the SET clause makes 
identical changes to all the selected tuples, then only the 
second method should be used. The SEQUEL assignment 
statement allows the result of a query to be copied into a 
new permanent or temporary relation in the database. This 
has the same effect as a query followed by the RDI operator 
KEEP. The execution of an assignment statement by the REI is 
done in two parts: 

1, The records satisfying the query are retrieved, 

2, A new relation is created with the records retrieved 

in (1) . These records are then stored in the 

database. 

A series of examples will be given for inventory 
database by using ORACLE relational DBMS in Chapter 9. 

^ • Cpt imizer 

The objective of the optimizer is to find a low cost 
means of executing a SEQUEL statement, given the data 
structures and access paths available. The optimizer 
attempts to minimize the expected number of pages to be 
fetched from the secondary storage into the RSS buffers 
during execution of the statement. Only page fetches made 
under the explicit control of the RSS are considered. If 
necessary, the RSS buffers will be pinned in real memory to 
avoid additional paging activity caused by the operating 
system such as the VM/370 operating system. The cost of the 
CPU instructions is also taken into account by means of an 
adjustable coefficient which is multiplied by the number of 
tuple comparison operations to convert to equivalent page 
accesses. The adjustable coefficient can be adjusted 
according to whether the system is computation-bound or I/O 
bound[Eef. 6]. 
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After analyzing any SEQUEL statement, the optimizer 
produces an Optimized Package (OP) containing the parse tree 
and a plan for executing the statement. If the statement is 
a query, OP is used to materialize tuples as they are called 
for by the fetch command. If the statement is a view 
definition, the OP is stored in the form of a Pre -Optimized 
Package (POP) which can be fetched and utilized whenever an 
access is made via the specified view. If any change is made 
to the structure of the base table or to the access paths 
maintained on it, the POPs of all views defined on that base 
table are invalidated, and each view must be reoptimized 
from its defining SEQUEL code to form a new POP. 

C. TBE REIATIOHAL STORAGE SYSTEM 

The BSS is essentially a powerful access method. Its 
primary function is to handle all details of the physical 
level and to present its user with an interface called the 
RSI. The user of the RSS is normally not a direct user, but 
is code generated by the EDS in compiling some SEQUEL 
statement. The RSI was specifically designed to be a good 
target for the SEQUEL compiler. 

As shown in Figure 8.3, the basic data object at the RSI 
is the stored file which is the internal representation of a 
base table. Rows of the table are represented by records of 
the file; the stored records within one stored file need not 
be physically adjacent in storage. An arbitrary number of 
indexes over any given stored file is supported by the RSS, 
thus providing the additional access paths to that file. Ihe 
RSS objects (stored files, indexes, etc. ) and the associated 
operators together constitute the Research Storage 
Inter face (RSI) . As lentioned above it is the interface used 
as the target by the RDS in precompiling SEQUEL requests. 
The user of the RSI needs to know what stored files and 
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indexes exist, and must specify the access path (index or 
system sequence) to he used in any given ESI access request- 

1 . Segments 

In the ESS, all data is stored in a collection of 
the logical address space called SEGMENTS, which are 
employed to control physical clustering. Segments are used 
for storing user data, access path structures, internal 
catalog information, and intermediate results generated by 
the EDS. All the tuples of any relation must reside within a 
single segment chosen by the EDS, but a given segment may 
contain several relations. Three types of segment are 

supported, each with its own combination of functions and 
overhead: shared (or public) , private, and temporary data 

segments. Basically data in shared segments are recoverable 
and sharable; data in private segments are recoverable but 
not sharable; and data in temporary segments is neither 
recoverable nor sharable. Segment type is fixed at the time 
of the system installation and cannot be changed. Each 
segment consists of a sequence of equal- sized pages which 
are referenced and formatted by various components of the 
ESS. The ESS maintains a page map for each segment which is 
used to map each segment page to its location on disk. At 
ESI, segments are identified by a numeric segment 
identifier. Pages are identified by page number within 
segment. Pages are never directly referenced in SEQUEL. 

2 • fil^ and Bec ords 

Each base table is represented as a stored file. A 
stored file is identified at the RSI by a numeric identifier 
called as EID. In ether words, a RID identifies a stored 
file. The EDS is responsible for mapping SEQUEL table-names 
to RDIs. Records in the stored file represent rows of the 
table. Each record is stored as byte string. The byte string 
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consists of a prefix, (containing control information, such 
as the EID of the containing file) , followed by the stored 
representation of each field in the record. Like segments 
and files , individual tuples have their own numeric 
identifier, called a TID. The TID for a tuple consists of 
two parts: page number of the page containing tuple, and a 

byte offset from the bottom of the page identifying a slot 
that contains, in turn, the byte offset of the tuple from 
top of the page. Operators are available to INSERT and 
EELETE single tuples, and to FETCH and UPDATE any 
combination of fields in a tuple. 

3 . I mages and Links 

An image in the ESS is a logical reordering of an 
n-ary relation with respect to values in one or more sort 
fields. Images combined with scans provide the ability to 
scan relations along a value ordering for low level support 
of simple views. An image provides associative access 
capability. The EDS can rapidly fetch a tuple from an image 
by keying on the sort field values. A new image can be 
defined at any time on any combination of fields in a 
relation. Each of the fields may be specified as ascending 
or descending. An image can also be dropped at any time. 
The ESS maintains each image through the use of multipages 
index structure. A new page can be added to an index when 
needed as long as one of the pages within the segment is 
marked as available. The pages for a given index are 
organized into a balanced hierarchic structure- Each page 
is a node within the hierarchy and contains an ordered 
sequence of index entries. 

A link in the ESS is an access path which is used to 
connect tuples in one or more relations. The EDS determines 
which tuples will be on the link and determines their 
relative position by using explicitly the CONNECT and 
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DISCCNNECT operations. The RSS maintains internal pointers 
so that newly connected tuples are linked to previous and 
next twins, and previous and next twins are linked to each 
other when a tuple is disconnected. 

^ • Transactio n Management 

a transaction at the ESS is a sequence of ESI calls 
in behalf of one user. In general, an RSS transaction 
consists of those calls generated by the RDS to execute all 
EDI operators in a single System R transaction, including 
the calls required tc perform such RDS internal functions as 
authorization, catalog access, and integrity checking. An 
ESS transaction is marked by the START-TRANS and END-TEANS 
operators. A transaction save point is marked as the 

SAVE-TEANS operator, which returns a save point number of 

subsequent reference. In general, a save point may be 
generated by any of the layers above the ESS. An EDI user 
may mark a save point at a convenient place in this 

transaction in order to handle backout and retry. The RDS 
may mark a save point for each new set oriented SEQUEL 
expression. Transaction recovery occurs when the EDS or 
Monitor issues the EESTORE-TEANS operator, which has a save 
point number as its input parameter, or when the RSS 

initiates the procedure to handle deadlock. The transaction 
recovery function is supported through the maintenance of 
the time ordered lists of log entries, which record 
information about each change to recoverable data. Those 
changes include all the tuple and image modifications caused 
by INSERT, DELETE, and UPDATE operations and all the link 
modifications caused by CONNECT and DISCONNECT operations. 

5 . Con currency Ccntrol 

Since System E is a concurrent user system, locking 
techniques must be employed to solve various synchronization 
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problems, both at the logical level of objects like 
relations and tuples and at the physical level of pages. At 
the logical level, such classic situations as the "lost 
update" problem must be handled to insure that two 
concurrent transactions do not read the same value and then 
try to write back an incremented value. If these 
transactions are not synchronized, • the second update will 
overwrite the first, and the effect of the increment will be 
lost. At the physical level of pages, locking techniques are 
required to insure that internal components of the ESS give 
correct results. 

6 . loc kin g 

Cne basic decision in establishing System R was to 
handle both logical and physical locking requirements within 
the ESS, rather than splitting the functions across the EDS 
and ESS subsystem. Ehysical locking is handled by setting 
and holding locks on one or more pages during the execution 
of a single RSI operation. logical locking is handled by 
setting locks on such objects as sequence, relations, tuple 
identifiers (TIDs) , and key value intervals and holding them 
until they are explicitly released or to the end of the 
transaction. Another basic decision in formulating System E 
was to automate all of the locking functions, both logical 
and physical, so that a user can access shared data and 
delegate some or all lock protocols to the system. 

In order to provide reasonable performance for a 
wide spectrum of user requirements, the ESS supports 
multilevels of consistency which control the isolation of a 
user from the actions of the other concurrent users [Ref. 2]. 
When a transaction is started at the RSI, one of three 
consistency levels must be specified. Different consistency 
levels may be chosen by different concurrent transactions. 
Por all of these levels, the ESS guarantees that any data 



modified by the transaction is not modified by any ether 
until the given transaction ends. The differences in 
consistency levels occur during read operations. level- 1 
consistency offers the least isolation from the other users, 
but causes the lowest overhead and lock attention. TTith this 
level, dirty data may be accessed, and one may read 
different values for the same data item during the same 
transaction. In level-2, the user is assured that every item 
read is clean. However, no guarantee is made that subsequent 
access to the same item will yield the same values or that 
associative access will yield the same item. For the highest 
consistency level (which is level-3) the user sees the 
logical equivalent of a single user system. Every item read 
is clean, and subsequent reads yield the same values, 
subject to updates by the given user. Level-3 consistency 
eliminates the problem of lost updates and also guarantees 
that one can read a logically consistent version of any 
collection of tuples, since other transactions are logically 
serialized with the given one. 

The ESS components set locks automatically in order 
to guarantee the logical functions of these various 
consistency levels. The ESS employs a single lock mechanism 
to synchronize access to all objects. This synchronization 
is handled by a set cf procedures in every activation of the 
ESS, which maintains a collection of queue structures called 
GATES in shared, read write memory. An internal request to 
lock on an object has several parameters: object name, lock 
mode, and indication cf lock duration. There are several 
factors which will effect the choice of lock duration such 
as the type of action requested by the user and consistency 
level of the transaction. Data items can be locked at 
various granularities to insure that various applications 
run efficiently. Lock on a single tuple will be effective 
for transactions which access small amounts of data. locks 
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on entire relations cr even entire segments will be more 
reasonable for transactions which cause the RDS to access 
large amounts of data. For accomplishing these situations, a 
dynamic lock hierarchy protocol has been developed so that a 
small number of locks can be used to lock both few and many 
objects. 

7 . Deadlock 

Since locks are reguested dynamically, it is 
possible for two or more concurrent activations of the ESS 
to deadlock. The RSS has been designed to check for deadlock 
situations when requests are blocked and to select one or 
more victims for backout if deadlock is detected. The 
detection is done by the Monitor on a periodic basis by 
looking for cycles in a user-user matrix. The selection of 
victim is based on the relative ages of transactions in each 
deadlock cycle as well as on the duration of the locks. In 
general the HSS selects the youngest transaction whose lock 
is of short duration, since the partially completed call can 
easily be undone. If none of the locks in the cycle are of 
short duration, the youngest transaction is chosen. This 
transaction is then backout to the save point preceding 
offending lock request, using the transaction recovery 
scheme. 
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IX. laPIIHEHTiTION BY DSING O BACLE 
A. IHTEODDCTION 

The CEACLE Eelational Database Management 
computer program that manages pieces of data 
computer. ORACLE allows access to this data 
sets cf commands that tell the computer what t 
commands are in a language that is called SQ 
several facilities fcr data manipulation. Some 
he used for the Inventory Database. 

All data in ORACIE are stored as tables. lab 
up of columns and rows. The SUPPLIER table sho 
four columns (SUPP_NAKE, COUNTRY, ADDRESS, an 
and four rows. A icw is made up of fields, 
contains a data value stored where a column an 
For example, the first row in the SUPPLIER ta 
data value ITT stored in its SDPP_NAHE field, th 
USA stored in its CCUKTRY field, P0.B0X.9 st 
ADDRESS field, and the data value S.F stored 
field. A database can contains many tables. 0 
the creation of as many tables as needed. All 
stored in ORACLE make up the database. 

We can create a table using the CREATE TA 
The ccmmand that creates the P ART_IDENTIFICATIOH 
follows : 

P 

CPeate table oar t 1 :Jent M i : at i on 
( nsn«-no c har ( 1 U I , 

t ot ♦•qt y^-on^hanrl njmoerCb)# 

'T'a * ►au t 3t y^Kand number(6)^ 
s uT>*»o ^ ♦‘u s e d«“un i t number(b) ) 

Table created. 



UFI> 

1 

2 

3 

a 



System is a 
stored in a 
by providing 
o do. These 
L. SQL has 
of them will 

les are made 
wn below has 
d SHIP_TYPE) 
Each field 
d row meet. 



ble has 


the 


e data 


va 


lue 


ored 


in 


its 


in it 


s C 


ITY 


RACLE 


all 


ows 


the 


tables 


BLE CO 


amia 


nd. 


table 


is 


as 
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In the CREATE TABLE conunand we name the table 
FART_IDENTIFICATION and the columns of the table (NSN_NO, 
TOT_QTY_CN_HAND, HA X_AUTH_QTY_HAND, SUd_OF_aSED_UN IT) . We 
specify if the coluirn is to contain only numeric values 
(NUMBER) or character (both numbers and letters) values 

(CHAR). We also specify the maximum length of the value 
that can be stored in the- column. For exaiaple, no NSN_NO can 
be longer than 14 characters- nsn_no char ( 14) . 

After a table is created# rows can be entered into the 
table using the IHSEBT command . The following command is 
used to enter the first row into the PART_IDENTIFICATION 
table . 

UFI> insert into oa r t •- 1 rien t i f t c a t i on 

2 values (’liaa-pai-iliii', 15000,20000,10000); 



PART_IDENTIFICATION into which the row is to be inserted and 
list the data values that go into each column. 

In a similar manner using the CREATE TABLE command, all 
tables in the inventory database are created and using the 
INSERT command all data are inserted into tables. The final 
version of the tables are shown below. 

PART_IDENTIFICATICN 

UFI> select * 



In the INSERT command 



we 



nn me 



the table 




NSNrNO 



TOl^-^TY^-nM^-HAm SU'^^0F^USE0«-UNIT 



1 5a2-?Ml-qi 1 1 
aa2i-3i 1-y 11 1 
aqsi-3i?-'4i IS 

si 11 - 1 1 1-151 n 

251 1-Sl l-qsi 1 
1015-512-51 12 
751 l-fe3a-533? 



15000 
1 0000 
5000 
25000 
1 0000 
2000 
1 5000 



aooon 
1 5000 
1 0000 
1 0000 
1 5000 
y 000 
25000 



3 0 0 0 0 

?nouo 

9 0 0 0 0 
1 5000 
20000 
1500 
1 25000 



7 records selected 
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DCCDMENT^IDEMTIFICATICN 



UF I > se ^ ec t * 

2 from doc J'^'en t i den t i f i c a t 1 on r 



^5N*-N0 DQCU SUPP 



I I n 1 t ow I i 1 1 

2a2 1 -5l 1 1 1 *5 t om I i 1 1 
2U5 I -5 1 2*^ 1 ^ ^ tom2 asal 
51 t 1-1 I l-lSM toml asal 
255l-5ll*S«n tonl dec 
1511-21 5-Sl 1 1 tom5 ib-n 
1 0 15-51 2-Sl 1 2 tom? dec 
7511-652-3352 tom5 asal 

8 records selected# 



UNIT INVENTORY 



UFI> select * 

2 from uni t nvent orv ? 



J^aT♦•c 


viSNt-MO^USE 


QTY*-ON*-HANO 


USED^'A'^QJNT 


2E O^AMOUM 


l oase 


1 iya-2'41 -ai 1 1 


7500 


50000 


2500 


1 oase 


2U21-31 l-ui 15 


2000 


1 0000 


3000 


2oase 


2U12-31 l-iU 15 


3000 


1 0000 


2000 


2oase 


2'»5t -312-ui IS 


1 250 


aooo 


750 


ioase 


2«51 -312-41 1 7 


1 250 


aooo 


750 


5oase 


2511-511-4511 


5000 


20000 


2000 


y oas e 


151 1 -215-51 1 1 


6250 


7500 


3200 


Soase 


1511 -215-511 1 


5000 


20000 


2000 


6oase 


7511 -632-6532 


600 


1 000 


aoo 


7oase 


1015-512-51 12 


aoo 


500 


200 


Soase 


1015-512-51 12 


1 250 


5000 


5250 


^oase 


5111-111-5111 


7500 


25000 


1 0000 
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DNIT ID 



UFI> select ♦ 

2 from u^it^id# 



SUOEC^I LOCAflO'J 



1 3ase 


2r af 


1 5N20E 


2oase 


2t a f 


25N50E 


5oase 


5taf 


21N52E 


^dase 


4t a f 


56N21E 


5oase 


at af 


aON22E 


boase 


1 taf 


51N25E 


7oase 


1 t a f 


57N25E 


6 oase 


2t a f 


58N25E 


Poase 


5 1 a f 


aiN2lE 



^ records selected. 



PAET ORDER 



UP’I> select * 

2 froT' oarr«-order; 



NSN«-N0 OATES A»^mjNT SHIP 



1 3a2-2ai-iU 1 1 itt 
2U51-312-41 15 asftl 
5111-111-1511 itt 
1511-215-5111 dec 
2511-512-5111 asal 
2015-512-51 12 itt 
2015-652-9552 iom 



051695 


2500 


a i r 


012595 


5000 


sea 


051695 


5250 


a i r 


0 1 1 685 


5250 


sea 


051 785 


5000 


sea 


042595 


600 


a 1 r 


052795 


1 0000 


a \ r 



7 rec or ds s e 1 ec t ed . 
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DIPOl STOCK LEV21 



JP“I> select * 

2 from depo t ►s t oc k *- 1 e ve 1 ? 



OEPO^ STOCKrA^OUMT SU^P >4SN^N34-R£G1 ST 



1 3a2-2qi-ai 1 
2q^l-3l 1-qi 15 
3^51-31 ^-al 15 
251 1-312-ql 15 
1015-512-5112 
7S1 1-662-8332 
151 1-215-51 1 1 
5111-111-5111 



8 records selected. 



depo 1 
deoo2 
deoo3 
deopq 
deoo5 
deoo6 
deoo 7 
deoo8 



7500 
5000 
2500 
5000 
1000 
7500 
1 1250 
1250 



i 1 1 
asa 1 
1 hm 
dec 
i pm 

dec 

i bm 
as a 1 



SDPPIIEE 



I > select * 

2 tron sjDDlier; 



SJPP 


COJNTR 


ADO^RESS 


CITY 


i 1 1 


US 8 


p D • bo X . P 


S,F 


i om 


u s a 


Pd.Dox, 12 


L . A 


dec 


u s a 


D d • DO X • 1 1 


N. Y 


asa 1 


t ur 


D 0 • DO X • 7 


i Z m i r 
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B. SAMPIE QDEEIES 



1. List national stock nuater of the items for 
quantity on hard equal 10000. 



select nsn»-no 

2 fram oa r f *■ i dent i f 1 c a t i on 

3 where t ot *"qt y<-on«-hand = 10000; 



MSN4-N3 



?'42l-ll i-«i 1 1 

2511-511 -asi 1 



2. Display nsn_no which is in the Ibase ani 
amount greater than 2500. 



L)P‘I> select nsn^-no^-usp 

2 frr>m u i t *■ i n V en t o r y 

3 ^Here unit*-code = 'Inase* 
^ ann r •qt-a-noun t > ?S00; 



NSN<-ND^ JSE 



2421 -511-4115 



which the 



re -]uirei 
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3. List all bases which are under command of 2taf. 



|JFI> select u'lit^'code 

2 froni u'^it^id 

3 Inhere suoer i or«-c onrir = *2taf* ? 



uNn«-c 



l oase 
2 Ddse 
Boase 



4. List all locations of tases which are under ccDrmand 
of Itaf. 



Ur I> 
2 
3 



select u'^it*-co'je 

from 



oc d t too 



-#he r e 



’ Itaf 



U'UT«-C LOCAflON 

fasase JlvaSE 
^Dase J7'J25E 
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5 



List all suppliers names and their addresses in the 
USA- 



UP‘I> select 5 jDo^od-ne # add re ss f c i t y 
2 f r o-n s JD3 Her 
5 *rf^ere cojntry s *usa* ; 



SJPP ADDRESS 



CIT f 



i 1 1 00 .box ,9 

i Dm DO . box • 1 ? 
dec DO .box . 1 1 



S.F 
L. A 
N.t 



6- Find total quantity on hand^ document^ and supplier 
name for items for which the sum of used amount is 
greater than 1C00. 

L)FI> select t 0 1 •-q t y **o o** h and , d oc jmen t # SUDD a “n e 

3 frDfT) Ddrt*'identificationrdocijmenf4-identMication 
3 -^h?re s u Ti*-o f ♦'u 3 e 1*“un » t > 1000 

^ and Dart ri dent i f i cat 1 on . = doc ume n r den t ^ H c a t i on . n snmo ; 

rDrrQTr«-0'J*-HA\J0 OOCJ SUPP 



15000 tom I itt 
50 00 t om3 asa 1 
30 0 0 t om 2 dec 
15000 tomS asal 
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7 



Find total used amount for Ibase 



UP1> select s jm ( usei«-amount ) 

2 from u T i t i n ve n t 0 r y 

3 where jnit^code - Mbase* ; 

SUM( JSE0«-A viOjNT) 



aoooo 



Find nsn_no and total ijuantity 
order by tot_gty_on_hand for 
maximum authorized quantity on hand is 
1500 . 



on hand in descending 
items for which the 



greater than 



U^I> select nsnt-no » t Ot ►at v*-on*-ham 

2 from oar t ► ) den t 1 < » c a t i on 

3 tifiere ^a * ►au t h f-qt y ►hand > 1500 
^ Ohder dy t dt ►qt y ►on^hand disc } 



NSN^NO I0T^I3TY»aN^H*ND 



5111-111-15111 


?5000 


1 3«2-?ai-t)l 1 1 


1 5000 


751 1 -652-8332 


15000 


2U21-31 1-0111 


1 0000 


251 1-51 1-051 1 


10000 


2051-31 2-01 1 5 


5000 


1015-512-51 12 


?000 


7 records selected. 
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9. Display total quantity on hand and sum of used amount 
for items supplied by ASAI. 



UFI> select t ot ♦-qr yi-on^-handf s ♦•used**uni t 

2 from oart^- i dent i f i c at i on 
5 where ns n^-no i n 
^ (select nsn**no 

5 from doc ument i den t i f i c a t < on 

6 where suop^-name = *asat*)# 



TDT^QTY<-0N«-HAS0 SUM^-OF^-USED^'UNIT 



5000 90000 

15000 125000 



10 . 



Find order amount^ dates^ and shipment 
items which are in the IDASE inventory. 



type for 



iJFI> select amount#dates»shiortyoe 

2 from part^order 

3 where nsn^’oo in 

^ ( select nsn^-no^-use 

5 from u n i t ^ i o V e n t o r y 

^ where jnit«-co(ie ^ 'lease'); 



A'^ujNT Dates ship 



2S00 031605 air 



103 



11. 



12 . 



Find required dmount and order aaiount for 
the 2BASE inventory. 



select req#-amount , aTiount 

2 from UT i t i n ven t or V , oar t ♦►or der 

3 Inhere jn i t ►i nvent ory ,uni t**code = *2base* 

^ and Lini t ►i nv^ntory .nsn«-no«- jse = oa r t ♦-or der . nsn^no ; 

REQ*-A'<ojNr amount 



750 5000 



Find total guantity on hand and maximum 
amount on hand for items for which 
1015-512-5112. 



'JPI> select tofqty<-on..hand,m,,.auth^nty^hanO 
^ fro-ti Dart«-tdentt f ication 
3 -<h?r» ">s-»«-no = * 1 0 1 5 -5 1 2 -5 I 1 2 • ; 



T3T#-QT Y«-0N*-dAMD M A X ► A u T H ♦-•! T Y«- d A NO 
2000 ^4000 



items in 



authorize 
nsn nc is 
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X. COHClOSlOHS AMD HECOMaE MDA TIOHS 



An inventory database system is complex and important. 
In order to effectively command and control the inventory of 
an Air force, the commander must Jcnow the status of his 
resources which will present the state of operational 
readiness of the Air Force. It is difficult to obtain 
accurate information from the inventory system by using the 
manual systems. The database management system must be used 
in the inventory systems in order to increase end-user 
productivity, decrease staff, and enable work to be done more 
efficiently. 

The complex task of a logical database design for a 
relational database management system can be greatly 
simplied by use of the Semantic Data Model. SDH is a 
high-level seman ti cs-based database description and 
structuring formalism for the database and enhances 

usability of the database system. Using the output of SDH in 
the Inventory Database, the records are rearranged in crder 
to fit a relational model. ORACLE DBMS was used for 
implementation. Functionality of ORACLE DBMS is very high 
and provides User Friendly Interface ( UFI ) . It is easy to 
use fcr all potential users. 

Finally, database machines are being developed in 
universities and research laboratories. It is obvious that a 
great deal of effcrt is being devoted to developing, 
studying and analyzing database computers. These efforts 
will result in guality hardware and software for all 
potential users of relational database management systems. 
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